On Tuesday 28 February 2017 09:18:01 Gene Heskett wrote:

> On Tuesday 28 February 2017 08:24:43 Gene Heskett wrote:
> > On Tuesday 28 February 2017 01:40:21 Erik Christiansen wrote:
> > > On 28.02.17 00:13, Gene Heskett wrote:
> > > > Plus values in the 0 to 7 range behave as expected.  updown
> > > > counts of -1 to -7 do not, but do give unique address outputs of
> > > > 15 to 9 in nibble values, so there is no conflict at any point
> > > > in the -7 to 7 range.
> > >
> > > The values: 15 to 9 for -1 to -7 are as expected here, Gene.
> > > That's 2's-complement representation of a negative number,
> > > straight out of the book.
> >
> > But its a book I never studied up on. My work in electronics all my
> > life was only concerned that it worked. And that, with the exception
> > of a defective z-80 I tried to write code on in about 1981, it was
> > one line, or bit at a time. I have only about 4 months of high
> > school freshman for official education. Digital electronics in
> > everyday stuff was a decade or more into the future then.
> >
> > Back to the future, eg today..
> >
> > This isn't a problem as I put the negative values in ascending value
> > into the descending address starting at 1111 if useing a mux16.  But
> > after looking at that on screen, I think a mux8 could handle it,
> > counting from 0 to 5 (could be expanded to 7 but thats awful fast)
> > only, and use the direction (obtained from velocity) bit to reverse
> > the starting reference.  That way we aren't hunting for the center
> > position. Just turn right for more speed, and left for less, and
> > overshooting isn't possible. By dealing only with 0 and positive
> > values in the updown, displaying it in pyvcp gets a lot easier too.
> >
> > > OK, it could have been 1's-complement, i.e. one less at each
> > > value, but that's a less used representation, though easier to
> > > generate. Nibble-wise, subtract 7 from 16 and you have 9, and
> > > that's what you're seeing. (I'm a little bit puzzled over what
> > > else could be expected.)
> >
> > Not having this 2's complement in my basic math education, I had to
> > set it up and experiment to find out. With this list as amused
> > witnesses. :)
> >
> > > I can visualise the jogging pulses being counted up/down,
> > > depending on which jogwheel phase comes first (i.e. CW or CCW),
> > > but that 1/2/5 scaling needs to always generates a positive mux
> > > address, I figure.
> >
> > We are in violent agreement I believe Erik. Using the direction to
> > do a scale -1 on the data generator that feeds the mux8's inputs
> > seems simpler to do too.
> >
> > The biggest problem will be getting all the conversions from u32 to
> > floats and back, at the right place in the processing path.
> >
> > We, for this, need a batch of modules that deal with s or u 32's
> > natively since this is all "integer" math, and I'm stuck with floats
> > for much of it. Floats are a lot slower, and I may see if, on the pi
> > at least, setting up another slower thread running at 100Hz as a way
> > of unloading some cpu cycles. The ability to setup an
> > if/then/else/end thing right in the addf's could sure ease the cpu's
> > task considerably in this case. Call it jog-thread in the addf's. 
> > Given that we are dealing with human fingers, 100Hz ought to be fast
> > enough for this.
> >
> > There are very few potential Thell Reed Jr's on this planet.
> > Probably long since retired from the marines now, but circa 1962 he
> > made a 13 frame long movie at Camp Pendleton. Starting with an empty
> > coke can on the back of each outstretched hand, he drew two army
> > 45's, and put 13 holes in each can before they hit the dirt. They
> > were not converted to full auto, he was pulling the triggers in time
> > with the slides going back into battery. Not well shown in those 13
> > frames was a mattress on the ground behind him because 26 rounds in
> > 1/2 second knocked him back on his butt. The funny part was that he
> > was then 17, having lied about his age to get into the Marines when
> > he was 16. One could say he had the "knack".
> >
> > 100Hz is still faster than that...  Next experiment...
>
> Which failed, the thread was not created. With these two lines in the
> [EMCMOT] section of the .ini file:
> SERVO_PERIOD  =       1000000
> JOG_PERIOD    =       10000000
>
> And moving most of the jogging stuff like this from the .hal file:
> # jogwheel stuff
> addf  xgainup                                         jog-thread
> addf  xgaindown                                       jog-thread
> addf  zgainup                                         jog-thread
> addf  zgaindown                                       jog-thread
> addf  jogsteerx                                       jog-thread
> addf  jogsteerz                                       jog-thread
> addf  xcounter                                        servo-thread
> addf  zcounter                                        servo-thread
> addf  conv-s32-u32.0                                  jog-thread
> addf  conv-s32-u32.1                                  jog-thread
> addf  muxaddrx                                        jog-thread
> addf  muxaddrz                                        jog-thread
> Gets me this at invocation time:
> HAL: ERROR: thread 'jog-thread' not found
> ./hm2-7i90-stepper.hal:80: addf failed
>
> Gotta go fix the better half some breakfast. later.

Looking up [EMCMOT] which for threads points at "motion"
and I find this after an unused BASE_PERIOD:

• servo_period_nsec = 1000000 - This is the Servo task period in 
nanoseconds. This value will be rounded to an integer multiple
of base_period_nsec. This period is used even on systems based on stepper 
motors.
This is the rate at which new motor positions are computed, following 
error is checked, PID output values are updated, and so
on. Most systems will not need to change this value. It is the update 
rate of the low level motion planner.

• traj_period_nsec = 100000 - This is the Trajectory Planner task period 
in nanoseconds. This value will be rounded to an
integer multiple of servo_period_nsec. Except for machines with unusual 
kinematics (e.g., hexapods) there is no reason to
make this value larger than servo_period_nsec.
--------------
From my failure, I assume that thread names are not arbitrary, so I 
should name my togging thread as TRAJ_PERIOD = 10x servo period. Next 
try...

That also fails, on the same first line its used in the hal file. So it 
is not my use of a new name for this new thread.  The thread it appears, 
is not being created.

Why?

Thanks.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to