Back
[00:45:55] <rayh> Does emc2 have an error ramp from min_ferror to ferror?
[00:46:01] <SWPadnos_> dunno
[00:46:16] <SWPadnos_> I managed to get a single following error running cds
[00:46:16] <rayh> that's as good an answer as any.
[00:46:38] <SWPadnos_> actually, I got several errors that run, but that was only one run out of about 6
[00:46:49] <SWPadnos_> two thoughts about that:
[00:47:17] <SWPadnos_> 1) this isn't the new layout, and I'm not sure I have Chris' recent trajectory fixes
[00:48:24] <SWPadnos_> 2) I was messing with feed override - first at 200%, then 100%, then 50% (where the errors occurred), then 25%, then while varying it
[00:48:38] <rayh> regarding 1 -- mine is new from noon today
[00:49:28] <rayh> regarding 2 -- it is not just a simple case of doing something to fast.
[00:49:42] <rayh> like you say you can see it at a number of feedrates.
[00:49:51] <rayh> I found the location to be just about random.
[00:50:01] <SWPadnos_> yep, also different axes
[00:50:06] <rayh> yes.
[00:50:18] <rayh> Wish I'd kept a copy of the scope trace.
[00:50:28] <rayh> I may try to reproduce that after a bit here.
[00:51:44] <rayh> During motion the following error oscillates fairly rapidly but small and predictable
[00:51:58] <rayh> Then it just jumped off the scale in both directions.
[00:52:47] <rayh> looked like three or four waves and then the following error took over.
[00:55:30] <SWPadnos_> phone
[01:24:01] <rayh> I got a screen capture of a following error causing event.
[01:27:05] <cradek> can you post it somewhere?
[01:27:49] <rayh> [30347.317841] RTAPI: WARNING: module 'HAL_motmod' failed to delete shmem 02
[01:27:53] <cradek> can you figure out the actual value of the following error when it triggered? I wonder if there's a sign problem somewhere
[01:28:00] <rayh> also got that when I tried to restart.
[01:28:23] <cradek> wish jmk was around
[01:28:24] <rayh> sure I can put them in the dropbox.
[01:29:08] <petev> cradek, I noticed some of the HAL files still have old pin names for the estop stuff in motion
[01:30:38] <rayh> at www.linuxcnc.org/dropbox/ and named ferror1 ... ferror3
[01:30:47] <rayh> Three is a beauty.
[01:31:04] <rayh> Details the whole path of the ferror.
[01:31:46] <SWPadnos_> what's the INPUT_SCALE?
[01:32:04] <petev> that's the encoder count scaling
[01:32:06] <rayh> what you see is what there is.
[01:32:11] <rayh> 4k
[01:32:48] <rayh> this is univstep
[01:32:55] <SWPadnos_> ok. what happens if you change the offset to 0.0?
[01:33:05] <SWPadnos_> foes the long flat section overlay the grid line?
[01:33:06] <rayh> offset?
[01:33:07] <SWPadnos_> does
[01:33:13] <SWPadnos_> just under scale - the button
[01:33:51] <rayh> I'm not sure we understand. This event is long ago in a galaxy far away.
[01:34:23] <rayh> I started adding offset so I could display more than one axis at a time but it happened.
[01:34:23] <SWPadnos_> I understand, do you still have halscope open though?
[01:34:30] <rayh> No
[01:34:33] <SWPadnos_> ok
[01:34:50] <rayh> the center line is the zero.
[01:34:56] <rayh> if that is what you were questioning
[01:34:59] <cradek> what are the units here? millivolts?
[01:35:02] <SWPadnos_> and you're feeding output steps back into the encoders using the switches, right?
[01:35:12] <rayh> yes.
[01:35:15] <SWPadnos_> 20 milli-units per div
[01:35:41] <SWPadnos_> was that a yes to me?
[01:35:41] <cradek> what real-world thing does a volt of following error represent?
[01:35:50] <SWPadnos_> it represents 1 user unit
[01:35:55] <rayh> I have no idea
[01:36:06] <SWPadnos_> that's why there's no v after 20m on the scale
[01:36:29] <SWPadnos_> it's 20 milli-floats ;)
[01:37:20] <SWPadnos_> well - I'd bet that there's a bug in one of two places:
[01:37:23] <rayh> so we have about 0.120 inch of error
[01:37:50] <SWPadnos_> sort of
[01:38:03] <rayh> Interesting that it lags for one loop and then leads for one.
[01:38:09] <SWPadnos_> it looks like it glitches off by .06, then back the other way by 0.06, then back to 0
[01:38:17] <SWPadnos_> no - the smape is misleading
[01:38:20] <SWPadnos_> shape
[01:38:35] <rayh> smapes usually are.
[01:38:39] <rayh> but how so?
[01:38:46] <SWPadnos_> jmk has the scope draw diagonals from the end of one sample to the middle of the next, then a flat across the second half
[01:39:06] <cradek> is this hal_ppmc?
[01:39:07] <SWPadnos_> that should just be a negative then pisitive triangle
[01:39:14] <rayh> yep
[01:39:14] <SWPadnos_> positive
[01:39:31] <SWPadnos_> so - the two possible errors:
[01:39:38] <SWPadnos_> 1) the encoder readback software (my problem)
[01:39:55] <SWPadnos_> 2) the internal FPGA loopback (Jon,s problem)
[01:40:25] <SWPadnos_> there may be a glitch in the FPGA when a direction reversal happens, depending on when it occurs
[01:41:06] <petev> SWPadnos, I checked in a couple of PID test files for vital and mesa
[01:41:06] <SWPadnos_> though that would be a big glitch - 0.06 @ 4k/inch is 240 (I'm betting 256)
[01:41:16] <SWPadnos_> I saw the commits
[01:41:16] <petev> they run sin/cos to make a circle
[01:41:26] <petev> might be usefull for testing this
[01:41:29] <SWPadnos_> yep
[01:41:33] <cradek> I say it's .064 tall
[01:41:45] <cradek> which does make 256
[01:42:12] <rayh> Hi pete.
[01:42:18] <SWPadnos_> ray - are you sure your cable is IEEE1284?
[01:42:37] <SWPadnos_> and also short, running direct
[01:42:44] <SWPadnos_> (no switchboxes)
[01:42:48] <rayh> uh yep -- slightly modified by disconnecting pin 13.
[01:43:20] <SWPadnos_> ok - you did have some capacitive problems though (which is why you had to disconnect pin 13)
[01:43:21] <petev> hi ray
[01:43:26] <rayh> no switchboxes
[01:43:29] <SWPadnos_> ok
[01:43:52] <rayh> um no. I had a handshaking speed problem with jon's charge pump.
[01:43:55] <SWPadnos_> though it would be weird for the error to swing past 0
[01:44:34] <SWPadnos_> how did you disconnect pin 13?
[01:44:37] <rayh> my athalon64 is much to fast for the little test routine he put on the fpga.
[01:44:45] <rayh> snip.
[01:44:54] <SWPadnos_> snip where?
[01:45:01] <rayh> at the ppmc end
[01:45:07] <SWPadnos_> ah - ok, trace cut
[01:45:15] <SWPadnos_> ?
[01:45:19] <rayh> no in the cable end
[01:45:41] <rayh> I removed the shielding, snipped and taped the wire and put it back together.
[01:45:43] <SWPadnos_> ok - you cut out the pin, not the wire - got it. (just making sure the other wires were safe ;) )
[01:45:48] <SWPadnos_> ok
[01:46:01] <SWPadnos_> well in that case, it's possible that you did nick another wire
[01:46:17] <rayh> um no I don't think so!
[01:46:26] <SWPadnos_> of course not ;)
[01:46:27] <petev> SWP, I had trouble with the USC with IEEE rated cables
[01:46:52] <SWPadnos_> (I don't have IEEE cables at this point, but mine works OK)
[01:46:52] <rayh> jon's stuff can be touchy.
[01:47:05] <petev> Jon was playing some funny games with timing and clocks
[01:47:07] <SWPadnos_> heh - "Ray, the master of Understatement" ;)
[01:47:11] <rayh> * rayh goes digging for a cheape cable
[01:47:12] <petev> it never did work right
[01:47:25] <petev> even after he tweaked it
[01:47:57] <petev> though the USC board was less problematic than the PPMC
[01:48:05] <rayh> I don't have any problems that show up with his communication loop program.
[01:48:16] <SWPadnos_> I'm still wondering why the ferror would swing to both sides of 0
[01:48:18] <petev> yeah, that would run pretty good
[01:48:37] <petev> but when the machine was running, it seemed susceptible to noise
[01:48:46] <SWPadnos_> a missing bit in a sample would give you an error to one side, which would then go away the next cycle
[01:48:57] <SWPadnos_> (but I'd still like to eliminate the simple things)
[01:48:58] <rayh> I've not seen any of that here yet.
[01:49:31] <rayh> Nice trace though 'eh?
[01:49:42] <SWPadnos_> yeah - real good!
[01:49:51] <petev> rayh, have you checked the outputs with a real scope just to see what they look like?
[01:49:54] <rayh> so this 256 thing?
[01:49:55] <cradek> the 24-to-32 bit extension code is very different from emc1
[01:50:18] <rayh> No mine is burned up at the moment.
[01:50:26] <SWPadnos_> you should put the encoder.position on it next time - that way we can see if it's a feedback problem or a command problem
[01:50:47] <SWPadnos_> the 24->32 code is closer to Alex's code in the STG
[01:51:34] <rayh> encoder position would just make a diagonal line?
[01:51:49] <rayh> unless interrupted.
[01:51:50] <SWPadnos_> true - that would be hard to see
[01:51:52] <cradek> rayh: if it's working right, yes
[01:51:59] <SWPadnos_> maybe use a differentiator block
[01:52:34] <rayh> ah. that would produce a flat unless there was a big disturbance.
[01:52:39] <rayh> good plan.
[01:53:05] <SWPadnos_> at least, a shape that depends on the expected path
[01:53:12] <SWPadnos_> but close to 0
[01:54:21] <rayh> suppose I could do the same for the command.
[01:54:32] <cradek> if ((oldpos.byte.b2 < 0) && (pos.byte.b2 >= 0))
[01:54:32] <cradek> pos.byte.b3++;
[01:54:39] <cradek> I don't think I trust this
[01:54:51] <SWPadnos_> ray - can you also attach the scope_rt funct to the base_thread instead of servo_thread?
[01:54:52] <cradek> b2 is signed
[01:54:59] <cradek> so this only tests one bit (the sign bit)
[01:55:13] <cradek> how can you tell if it's going up or down by testing one bit?
[01:55:19] <SWPadnos_> good point
[01:56:06] <cradek> the old code watched for transition of the top two bits together, which is better
[01:56:18] <cradek> rayh: do you want me to change it for you to try?
[01:56:19] <petev> what is byte? is this thing in a union with unsigned bytes?
[01:56:29] <cradek> no, they're *signed*
[01:56:36] <cradek> but yes, it's the union making a long
[01:56:49] <cradek> I don't understand why they're signed
[01:57:04] <rayh> cradek: I'm up for anything at this point. What did you want to change.
[01:57:08] <SWPadnos_> yep, though it's not just a single bit being checked, it's two (old and new sign), so there are 4 possible combinations
[01:57:13] <petev> It makes the FF rollover test easier
[01:57:23] <SWPadnos_> that would be a 16M error though
[01:57:28] <SWPadnos_> not a 256 error
[01:57:34] <cradek> who knows what the units are
[01:57:36] <petev> swp: yes
[01:58:01] <SWPadnos_> cradek: what do you mean (units)?
[01:58:01] <cradek> SWPadnos_: no, it's testing for a change of the top bit of b2
[01:58:24] <rayh> * rayh goes off to try to capture another glitch.
[01:58:30] <cradek> how many encoder counts make 20 mV?
[01:58:30] <SWPadnos_> yes, old = 1, new = 0 is one possibility, old and new the same is two more, then old=0, new=1
[01:58:34] <petev> cradek, is it b0, b1, b2, or b1, b2?
[01:58:45] <SWPadnos_> ray has scale set to 4000 counts per inch
[01:58:46] <cradek> 0,1,2
[01:58:49] <SWPadnos_> 0,1,2,3
[01:58:52] <cradek> 3 is faked
[01:58:57] <petev> ok
[01:59:00] <SWPadnos_> so 4 counts per milliunit
[02:00:15] <cradek> rayh: can you run emc1?
[02:00:57] <SWPadnos_> cradek: this may be a problem, but it isn't the problem Ray is experiencing, because it would be a 16Mcount glitch
[02:00:59] <rayh> Um I suppose I can on this same box.
[02:01:23] <cradek> rayh: I think you should try that if you can
[02:01:30] <petev> swp: I don't see an issue with the code, I assume there is a simial if for the other direction?
[02:01:45] <rayh> what would i do with it run the same file?
[02:01:52] <cradek> sure, if you can
[02:02:03] <SWPadnos_> if ((oldpos.byte.b2 < 0) && (pos.byte.b2 >= 0))
[02:02:04] <SWPadnos_> pos.byte.b3++;
[02:02:06] <SWPadnos_> else
[02:02:07] <SWPadnos_> if ((oldpos.byte.b2 >= 0) && (pos.byte.b2 < 0))
[02:02:09] <SWPadnos_> pos.byte.b3--;
[02:02:19] <petev> ok
[02:04:45] <SWPadnos_> it should be impossible to get 16M counts between reads (in fact, at 100kcounts/inch, you'd have to have an 8300IPS travel to get 23 bits of change in a millisecond)
[02:05:47] <cradek> but you don't have to, do you?
[02:06:04] <SWPadnos_> hmmm
[02:06:07] <cradek> say l changes from 00 80 00 00 down to 00 7f ff ff (one count decrease)
[02:06:20] <cradek> the first test will fire, giving you 01 7f ff ff
[02:06:26] <SWPadnos_> that's not a 1 count change - the encoder position is signed
[02:06:29] <SWPadnos_> in the FPGA
[02:06:57] <cradek> a signed four byte value?
[02:07:04] <SWPadnos_> signed 3-byte value
[02:07:05] <cradek> my four-byte's sign didn't change
[02:07:15] <cradek> oh ok
[02:08:07] <SWPadnos_> I considered just sign extending, then keeping track of deltas
[02:08:24] <rayh> running BDI-4 generic.ini now - auto - cds.ngc - override 300%
[02:08:58] <SWPadnos_> I found that lower FO got errors - I never saw an error at >= 100% (this run, anyway)
[02:09:56] <rayh> I know it will run at these speeds. This was one of my standard tests for the BDI series since 2.04
[02:10:34] <rayh> 25% 50% 75% 100% ... 300%
[02:10:40] <SWPadnos_> ok.
[02:11:01] <rayh> the feedrate in cds is 16 ipm
[02:11:19] <SWPadnos_> I may change the encoder extending code to the emc1 way, just for giggles. tf that fixes it, that's good.
[02:11:27] <rayh> and yes it did run without incident on the K%T 800 at GM.
[02:11:39] <cradek> I already have done that - I can check it in if you guys want
[02:11:56] <SWPadnos_> it's OK by me
[02:12:10] <rayh> You can pass it to me to test if you wish. or commit and i'll pick it up.
[02:13:12] <cradek> committed
[02:13:22] <SWPadnos_> I don't think it's the problem though, because that would cause a 16Mcount error
[02:13:37] <rayh> cds is nearly done with no errors.\
[02:13:59] <cradek> SWPadnos_: I believe you
[02:14:14] <petev> that code looked ok to me
[02:14:19] <petev> I think it's something else
[02:16:18] <SWPadnos_> actually - that can't be the error anyway - I tested by moving past 0 in both directions, and the position is fine - the encoder gets zeroed at hal_ppmc startup
[02:16:51] <cradek> maybe I should let you guys with the hardware work on this
[02:17:39] <rayh> crap garbage left around will take me a while to cleanup all the modules.
[02:20:00] <rayh> guess its reboot time. brb
[02:24:51] <rayh> insmod: error inserting '/home/rayh/emcdevelop/emc2/rtlib/hal_ppmc.ko': -1 Operation not permitted
[02:24:51] <rayh> HAL:4: ERROR: insmod failed, returned 1
[02:24:54] <rayh> HAL config file /home/rayh/emcdevelop/emc2/configs/univstep/usc_motion.hal failed.
[02:25:40] <SWPadnos_> does it work if you run sudo emc?
[02:25:51] <rayh> that was a sudo
[02:25:57] <rayh> tried it both ways.
[02:26:07] <petev> whats the dmesg
[02:27:09] <rayh> [ 213.152553] RTAPI: WARNING: tried to delete task 01 while running
[02:27:09] <rayh> [ 213.165724] RTAPI: Exiting
[02:27:10] <rayh> [ 213.165745] RTAPI: Exit complete
[02:27:11] <rayh> [ 213.178503] RTAI[math]: unloaded.
[02:27:11] <rayh> [ 213.243630] RTAI[malloc]: vfreed extent e0f0d000, size 131072.
[02:27:11] <rayh> [ 213.243650] RTAI[malloc]: unloaded.
[02:27:12] <rayh> [ 213.343473] RTAI[sched_lxrt]: unloaded (forced hard/soft/hard transitions: traps 0, syscalls 0).
[02:27:14] <rayh> [ 213.357036] Adeos: Domain RTAI unregistered.
[02:27:16] <rayh> [ 213.357043] RTAI[hal]: unmounted.
[02:27:18] <rayh> [ 213.369615] Adeos: Pipelining stopped.
[02:27:21] <rayh> r
[02:27:35] <petev> anything before this?
[02:27:42] <SWPadnos_> or after?
[02:27:53] <petev> that looks like a shutdown
[02:28:28] <rayh> found the problem. had to remove the parport cable for emc1 run.
[02:29:53] <rayh> nope.
[02:30:54] <rayh> wonder if the crash got next to my bios parport settings. Had that happen before.
[02:31:00] <rayh> bye
[02:52:45] <rayh> ppmc seems to be borked.
[02:52:58] <rayh> axis 2 comes up with limits activated
[02:53:30] <rayh> removed those by hand but as soon as motion started 2 went to -16 and the system died.
[02:53:41] <SWPadnos_> do you know if it's + or - limit? (and which inputs those are connected to)
[02:54:14] <rayh> both
[02:54:54] <SWPadnos_> ok - I'm looking for the connections
[02:55:05] <rayh> 06 bit -W TRUE ppmc.0.din.09.in ==> Zminlim
[02:55:05] <rayh> 06 bit -W FALSE ppmc.0.din.09.in-not
[02:55:05] <rayh> 06 bit -W TRUE ppmc.0.din.10.in ==> Zmaxlim
[02:55:06] <rayh> 06 bit -W FALSE ppmc.0.din.10.in-not
[02:55:36] <rayh> 02 bit R- TRUE axis.2.neg-lim-sw-in <== Zminlim
[02:55:36] <rayh> 02 bit R- TRUE axis.2.pos-lim-sw-in <== Zmaxlim
[02:55:44] <SWPadnos_> tep
[02:55:49] <SWPadnos_> yep
[02:56:27] <SWPadnos_> can you give me the output on show pin ppmc.0.din
[02:57:33] <rayh> nope the system will not load again.
[02:57:54] <SWPadnos_> hmm
[02:58:14] <SWPadnos_> lemme look for recent changes to hal_ppmc.c - I don't remember any
[02:59:18] <rayh> acts like there is no board connected but there is and the green light is on.
[02:59:19] <SWPadnos_> ok, right - jmk was working onthe stepgens a couple of days ago
[02:59:39] <SWPadnos_> dmesg says no ppmc found?
[03:00:03] <rayh> something like that.
[03:01:21] <rayh> looks like another reboot.
[03:01:26] <SWPadnos_> k
[03:01:51] <rayh> I'm getting wound enough that I'll do something else for a while.
[03:02:03] <SWPadnos_> ok
[03:02:06] <rayh> Maybe take the customer that's waiting for this to turn motors out for a dring.
[03:02:25] <SWPadnos_> heh
[03:02:26] <rayh> maybe already had more than enough to trash typing.
[03:02:32] <SWPadnos_> could be relaxing
[03:02:43] <SWPadnos_> yoda speaking it is
[03:03:25] <rayh> did the switch of the 24->32 bit stuff a bit ago have anything to do with this?
[03:03:43] <SWPadnos_> I don't think so - that would cause a 16 million count error
[03:03:49] <SWPadnos_> (4000 inches)
[03:04:42] <rayh> has not run since that last cvs up.
[03:04:58] <SWPadnos_> when was that?
[03:05:06] <SWPadnos_> the one that restructured the configs?
[03:06:19] <rayh> no about 20 minutes ago.
[03:06:29] <rayh> after chris's commit.
[03:06:42] <SWPadnos_> ah. I'm pretty sure that isn't the problem
[03:06:50] <cradek> rayh: when you did the up, did just that one file change?
[03:06:57] <rayh> yes
[03:07:16] <rayh> running make again now.
[03:08:23] <rayh> nope something bad going wrong. KDM left the building the last time.
[03:08:52] <SWPadnos_> the login manager?
[03:09:24] <SWPadnos_> maybe you should do a power cycle, just for the heck of it
[03:11:10] <rayh> yes. It doesn't come back at all. terminal login and startx
[03:14:55] <rayh> It starts now but same axis 2 limits problem
[03:15:15] <SWPadnos_> ok - with it still running, get a terminal window you can run halcmd from
[03:15:43] <rayh> k
[03:16:04] <SWPadnos_> (we can still test stuff without dealing with unload/load problems)
[03:17:24] <rayh> can't get machine on until I break the limit links and switch the value of the signals.
[03:18:08] <cradek> how has anything like that recently broken?
[03:18:08] <SWPadnos_> no need to get the machine on
[03:18:34] <SWPadnos_> there are a couple of things I'd like to know about that have nothing to do with motion
[03:19:32] <rayh> k
[03:19:56] <rayh> still kicks up a limit error box every now and then.
[03:20:27] <SWPadnos_> are you getting any messages in the system log?
[03:20:42] <rayh> dmesg
[03:20:47] <SWPadnos_> yes
[03:21:26] <SWPadnos_> or a separate terminal with tail -f /var/log/messages running
[03:21:57] <rayh> [ 207.414836] PPMC: checking EPP bus 0 at port 0378
[03:21:57] <rayh> [ 207.414842] PPMC: slot 0: EPP Bus Timeout!
[03:21:58] <rayh> [ 207.414856] ID code: 41 Univ. Stepper Controller
[03:21:58] <rayh> [ 207.414859] PPMC: exporting digital inputs
[03:21:58] <rayh> [ 207.414984] PPMC: exporting digital outputs
[03:21:59] <rayh> [ 207.415060] PPMC: exporting step generators
[03:21:59] <rayh> [ 207.415153] PPMC: exporting encoder pins / params
[03:22:43] <SWPadnos_> ok - leave a tail window running, see if any more EPP bus timeout messages happen
[03:23:40] <SWPadnos_> can you paste in the output of bin/halcmd show pin ppmc.0.din
[03:23:54] <rayh> it goes out to slot 15 and then accepts 0
[03:24:11] <SWPadnos_> oh - that wasn't the last of the log?
[03:24:30] <rayh> Component Pins:
[03:24:30] <SWPadnos_> ok. that's normal
[03:24:31] <rayh> Owner Type Dir Value Name
[03:24:31] <rayh> 06 bit -W FALSE ppmc.0.din.00.in ==> Xhome
[03:24:31] <rayh> 06 bit -W TRUE ppmc.0.din.00.in-not
[03:24:32] <rayh> 06 bit -W FALSE ppmc.0.din.01.in ==> Xminlim
[03:24:32] <rayh> 06 bit -W TRUE ppmc.0.din.01.in-not
[03:24:33] <rayh> 06 bit -W FALSE ppmc.0.din.02.in ==> Xmaxlim
[03:24:34] <rayh> 06 bit -W TRUE ppmc.0.din.02.in-not
[03:24:36] <rayh> 06 bit -W FALSE ppmc.0.din.03.in
[03:24:38] <rayh> 06 bit -W TRUE ppmc.0.din.03.in-not
[03:24:40] <rayh> 06 bit -W FALSE ppmc.0.din.04.in ==> Yhome
[03:24:42] <rayh> 06 bit -W TRUE ppmc.0.din.04.in-not
[03:24:44] <rayh> 06 bit -W FALSE ppmc.0.din.05.in ==> Yminlim
[03:24:51] <SWPadnos_> damn
[03:24:58] <SWPadnos_> heh - gotta get the pacing right
[03:25:29] <rayh> loose all of that?
[03:25:47] <SWPadnos_> I got up to din.05.in ==> YmimLim
[03:26:17] <rayh> 06 bit -W FALSE ppmc.0.din.05.in ==> Yminlim
[03:26:18] <rayh> 06 bit -W TRUE ppmc.0.din.05.in-not
[03:26:18] <rayh> 06 bit -W FALSE ppmc.0.din.06.in ==> Ymaxlim
[03:26:18] <rayh> 06 bit -W TRUE ppmc.0.din.06.in-not
[03:26:35] <rayh> 06 bit -W FALSE ppmc.0.din.07.in
[03:26:35] <rayh> 06 bit -W TRUE ppmc.0.din.07.in-not
[03:26:36] <rayh> 06 bit -W TRUE ppmc.0.din.08.in ==> Zhome
[03:26:37] <rayh> 06 bit -W FALSE ppmc.0.din.08.in-not
[03:26:37] <rayh>
[03:26:51] <rayh> 06 bit -W TRUE ppmc.0.din.09.in ==> Zminlim
[03:26:51] <rayh> 06 bit -W FALSE ppmc.0.din.09.in-not
[03:26:51] <rayh> 06 bit -W TRUE ppmc.0.din.10.in ==> Zmaxlim
[03:26:52] <rayh> 06 bit -W FALSE ppmc.0.din.10.in-not
[03:26:52] <rayh>
[03:27:10] <rayh> 06 bit -W TRUE ppmc.0.din.15.in ==> EstopSense
[03:27:11] <rayh> 06 bit -W FALSE ppmc.0.din.15.in-not
[03:27:20] <SWPadnos_> what about 11-14?
[03:27:41] <rayh> nothing connected
[03:27:51] <SWPadnos_> I still want to know what the usc thinks is going on
[03:28:10] <rayh> the usc is thinking everything is fine.
[03:28:25] <rayh> 06 bit -W TRUE ppmc.0.din.11.in
[03:28:26] <rayh> 06 bit -W FALSE ppmc.0.din.11.in-not
[03:28:26] <rayh> 06 bit -W TRUE ppmc.0.din.12.in
[03:28:26] <rayh> 06 bit -W FALSE ppmc.0.din.12.in-not
[03:28:34] <rayh> 06 bit -W TRUE ppmc.0.din.13.in
[03:28:34] <rayh> 06 bit -W FALSE ppmc.0.din.13.in-not
[03:28:35] <rayh> 06 bit -W TRUE ppmc.0.din.14.in
[03:28:36] <rayh> 06 bit -W FALSE ppmc.0.din.14.in-not
[03:28:48] <SWPadnos_> you mention nothing connected - I assume that nothing is aphysically connected to the unit, other than the estop stuff?
[03:29:05] <SWPadnos_> (and power nad the parallel cable, of course ;) )
[03:29:38] <rayh> Right
[03:30:04] <rayh> want the ppmc param as well
[03:30:08] <SWPadnos_> the entire upper byte of input is 1, and the entire low byte is 0 (or the other way around - I'm not sure if they're inverted in the FPGA)
[03:30:28] <SWPadnos_> that sounds like a problem with either the driver or the board
[03:30:57] <SWPadnos_> it could be an off-by-one error in indexes - hold on a sec
[03:32:01] <SWPadnos_> hold on a sec - I'm running emc2/ppmc right now, on a checkout I did today
[03:32:18] <SWPadnos_> this is my halcmd output:
[03:32:31] <SWPadnos_> Owner Type Dir Value Name
[03:32:33] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.00.in ==> Xhome
[03:32:34] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.00.in-not
[03:32:36] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.01.in ==> Xminlim
[03:32:37] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.01.in-not
[03:32:39] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.02.in ==> Xmaxlim
[03:32:40] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.02.in-not
[03:32:42] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.03.in
[03:32:43] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.03.in-not
[03:32:45] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.04.in ==> Yhome
[03:32:46] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.04.in-not
[03:32:48] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.05.in ==> Yminlim
[03:32:49] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.05.in-not
[03:32:51] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.06.in ==> Ymaxlim
[03:32:52] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.06.in-not
[03:32:54] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.07.in
[03:32:55] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.07.in-not
[03:32:57] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.08.in ==> Zhome
[03:32:58] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.08.in-not
[03:33:00] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.09.in ==> Zminlim
[03:33:02] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.09.in-not
[03:33:04] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.10.in ==> Zmaxlim
[03:33:05] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.10.in-not
[03:33:07] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.11.in
[03:33:09] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.11.in-not
[03:33:11] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.12.in
[03:33:13] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.12.in-not
[03:33:15] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.13.in
[03:33:17] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.13.in-not
[03:33:19] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.14.in
[03:33:22] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.14.in-not
[03:33:23] <SWPadnos_> 05 bit -W FALSE ppmc.0.din.15.in ==> EstopSense
[03:33:25] <SWPadnos_> 05 bit -W TRUE ppmc.0.din.15.in-not
[03:33:29] <SWPadnos_> I have inputs 15 and 14 connected together, to the SSR8 outptu
[03:33:31] <SWPadnos_> output
[03:34:35] <rayh> I don't see how tht is different from what I sent.
[03:35:02] <SWPadnos_> note that I have a nice false / true pattern, up to inputs 14 and 15 (connected to estop out)
[03:35:10] <SWPadnos_> your pattern ends at bit 8
[03:35:29] <SWPadnos_> and everything 8 and above is opposite (including Z home and limits)
[03:36:03] <SWPadnos_> so something's probably screwy with the board, or the cable
[03:36:19] <rayh> We went through all of this hardware stuff the other day
[03:36:32] <rayh> it was fine until I recompiled with cradek change.
[03:36:41] <rayh> Let me revert my stuff and proove it.
[03:36:53] <SWPadnos_> that would be good
[03:37:02] <SWPadnos_> did you do a make clean ; make, or just make
[03:37:19] <rayh> i did both.
[03:37:22] <SWPadnos_> ok
[03:37:36] <SWPadnos_> oops
[03:37:46] <SWPadnos_> I just noticed that I was running a slightly older version
[03:37:55] <rayh> now how do I step back. the cvs browse is a day old.
[03:38:01] <SWPadnos_> I tried some experiments as a normal user today, and never got things running
[03:38:33] <SWPadnos_> I'm not sure of the exact cvs command, something like cvs up -D yesterday
[03:39:00] <SWPadnos_> maybe with -dP and -C as well (though -C will clobber any changes you've made to any file in cvs)
[03:39:44] <rayh> looks like it's working
[03:40:36] <SWPadnos_> the cvs up?
[03:41:26] <rayh> nope system is still trash.
[03:43:30] <SWPadnos_> ok. I'm trying to get today's cvs (with your univstep config) running - it'll take a sec
[03:44:15] <SWPadnos_> what's a good setting for DEADBAND?
[03:44:41] <rayh> a bit more than half the distance between adjacent encoder counts.
[03:45:02] <SWPadnos_> ok (awfully small for me at 40k counts/inch ;) )
[03:45:25] <rayh> damn all my kde preferences are gone now.
[03:45:58] <SWPadnos_> ok - that's just weird. the kernel modules don't have access to files (though they could theoretically trash the filesystem)
[03:49:54] <SWPadnos_> OK - I got the univstep config to work. now I'll do a fresh checkout and see if that fails for me
[03:50:45] <SWPadnos_> hey - in tkemc, pressing 'a' doesn't select the A axis - is there another function that uses a, b, or c?
[03:51:42] <rayh> yes
[03:51:54] <SWPadnos_> ok - and I get immediate following errors with this config - excellent ;)
[03:52:03] <rayh> `123 select in manual
[03:52:16] <SWPadnos_> also 0, I noticed
[03:53:14] <rayh> been a long time since I looked at those bindings.
[03:53:45] <SWPadnos_> heh
[03:55:32] <SWPadnos_> are you trying to run with the univstep config you sent me (suitably fixed up)?
[03:56:00] <rayh> i think the second one was close to running.
[03:56:14] <rayh> I'm pretty sure that I did some editing on it after I sent.
[03:56:14] <SWPadnos_> ok - I didn't untar that one
[03:56:30] <SWPadnos_> I just added all the PIDFF items to the ini, and ZPos-cmd signal
[03:56:31] <rayh> The first didn't work out of the box.
[03:56:37] <SWPadnos_> I mean APos-cmd
[03:56:53] <SWPadnos_> ok - I have a new make running, just checked out
[03:57:03] <SWPadnos_> the other one was from about noon today, your time
[03:57:09] <rayh> Those should have been in the second I sent.
[03:57:27] <SWPadnos_> ok -are you using those exact settings now?
[03:57:40] <rayh> I'm not using anything.
[03:57:44] <SWPadnos_> heh
[03:57:56] <rayh> I've had about all the fun i can stand.
[03:57:57] <SWPadnos_> ok -are you using^H trying to use those exact settings now?
[03:58:03] <SWPadnos_> :)
[03:58:03] <rayh> doing a new checkout
[03:58:14] <rayh> should be done here in about 15 minutes more.
[03:58:14] <SWPadnos_> ok.
[03:58:39] <SWPadnos_> I'm going to copy the univstep config I just made over to the new build dir, and see if the signals look the same as before
[03:59:13] <SWPadnos_> the version from earlier today was identical to my few day old one
[03:59:25] <rayh> I did quite a bit of tuning this afternoon after sending that stuff.
[03:59:43] <rayh> want me to send a new set of all of it?
[04:00:36] <SWPadnos_> that would be good, just so I can fiddle with the parameters here (after you go to bed ;) )
[04:05:53] <SWPadnos_> still compiling (slow celeron 500)
[04:06:09] <rayh> just started make here.
[04:06:23] <SWPadnos_> ok (me = fast download, slow compile)
[04:07:52] <rayh> limit errors on x, y, and z this time.
[04:08:44] <SWPadnos_> ok - that really sounds like a problem with the board (though it did work with emc1 earlier)
[04:09:22] <SWPadnos_> can you stop and restart emc?
[04:11:08] <rayh> this is not a correct set. somewhere in the trashing I got em mixed up.
[04:11:19] <rayh> the io does not have the 4th axis.
[04:12:11] <SWPadnos_> that's OK - I only need to see pin data, don't need the machine "on" or out puf estop
[04:12:20] <SWPadnos_> s/puf/of/
[04:12:22] <rayh> nope i'm locked out of hal_ppmc.ko now.
[04:12:28] <SWPadnos_> ok
[04:12:46] <SWPadnos_> well - I'll let yo uknow wheen this compile finishes - maybe by the time you reboot
[04:13:49] <rayh> my guess is that it will not reboot.
[04:15:57] <SWPadnos_> hmmm - why is that? (aren't you on that machine?)
[04:16:29] <rayh> no the one next door.
[04:16:36] <SWPadnos_> ah - OK
[04:16:52] <SWPadnos_> ok - so you went inside for the evening? ;)
[04:17:34] <rayh> nope next door is about 2 inches.
[04:17:40] <SWPadnos_> ah
[04:18:01] <rayh> yes this time the startup ate all the font definitions and icon locations on the desktop
[04:18:11] <rayh> It is quickly sinking into the mud.
[04:18:19] <SWPadnos_> that is really strange shit
[04:19:51] <rayh> HAL:14: ERROR: parameter 'ppmc.0.stepgen.00-03.pulse-width' notfound
[04:20:23] <SWPadnos_> one sec
[04:21:07] <rayh> I think that's about it.
[04:21:23] <SWPadnos_> the IO looks identical with the fresh build
[04:22:21] <SWPadnos_> and I can definitely see that parameter, exactly as you named it
[04:23:24] <rayh> I've even lost the ability now to click and open files with kwrite.
[04:23:26] <SWPadnos_> in all these reboots, did you ever unplug the USC from both the parport and its power supply, just to give it a clean start?
[04:23:40] <rayh> yep.
[04:23:59] <rayh> will try again.
[04:24:13] <SWPadnos_> that UI stuff is just weird. I can't think of how emc could screw that up (other than some major memory fubar-ness)
[04:26:15] <petev> all this sounds a bit familiar to the problems I was having
[04:26:24] <petev> what BDI are u using ray?
[04:26:36] <rayh> 4.30
[04:26:40] <SWPadnos_> some kernel module is just scribbling all over memory everywhere
[04:26:44] <SWPadnos_> not necessarily emc
[04:26:45] <petev> hmm, I'm good on 4.30
[04:26:56] <petev> but the problem sounds the same
[04:27:24] <rayh> This is the last box that I have that is able to run emc.
[04:27:46] <rayh> suppose I'll have to take a day and rebuild everything.
[04:28:28] <rayh> okay univstep is up and running and failing on axis 3 again.
[04:28:40] <rayh> z rather
[04:28:58] <SWPadnos_> limits, or following errors?
[04:29:13] <rayh> limits
[04:29:24] <rayh> I can't get machine on at all.
[04:29:56] <rayh> can't type much here without limit messages getting in the way.
[04:30:02] <SWPadnos_> nope - the USC is telling emc that all of the top 8 inputs are on, so Z looks like it's at both limits simultaneously
[04:32:47] <rayh> well guys as usual it was real fun.
[04:34:16] <SWPadnos_> oh well. it looks like something other than emc is having fun with his system
[04:53:24] <petev> SWPadnos, u there?
[04:53:30] <SWPadnos_> kinda
[04:53:41] <petev> has alex tested the new emc script stuff?
[04:54:00] <SWPadnos_> as far as the config dirs, or the config wizard?
[04:54:10] <petev> just the script and dirs
[04:54:14] <petev> not wizard
[04:54:24] <SWPadnos_> I think so - are you having trouble?
[04:54:36] <SWPadnos_> (it works for me as well)
[04:54:38] <petev> yeah, things don't work right as far as paths
[04:54:45] <petev> and there are errors in hal files
[04:55:02] <SWPadnos_> ok - yes, not all of the configs are complete
[04:55:18] <petev> i thought u could do something like sudo ./scripts/emc m5i20
[04:55:22] <SWPadnos_> you do need to run ./configure to get the emc script to be built
[04:55:32] <petev> yeah, the script is there
[04:55:41] <SWPadnos_> you shouldn't need the sudo
[04:55:42] <petev> have u tried invoking it like I showed?
[04:55:57] <SWPadnos_> ok, but any changes need a re-configure to get the script updated
[04:56:00] <petev> I'll try without, but that's not hte problem
[04:56:14] <SWPadnos_> so every time you cvs up, you need to re-create the script (if there are any changes)
[04:56:19] <petev> try it like I showed with a dir name for arg
[04:56:28] <SWPadnos_> one sec
[04:56:44] <petev> I'll cvs up again
[04:57:01] <SWPadnos_> actually, that's what Ive been doing, just using univstep instead of m5i20
[04:57:14] <petev> so u give it dir name?
[04:57:32] <SWPadnos_> and it seems to work with or without sudo
[04:57:43] <petev> nothing pertinent looking on the update
[04:57:44] <SWPadnos_> yes - univstep is a config dir, in configs/
[04:58:06] <SWPadnos_> emc.in was changed earlier today, I believe (mostly related to sudo in teh script)
[04:58:15] <petev> yeah, that doesn't work for me, it builds bogus file names
[04:58:25] <SWPadnos_> ?
[04:58:30] <petev> just configured again after the update
[04:58:43] <SWPadnos_> like "cant find blahblah/modules/.ko" ?
[04:58:47] <petev> yes
[04:59:07] <SWPadnos_> there's no motion or IO controller specified in some of the ini files - you need to add the missing one(s)
[04:59:21] <SWPadnos_> the script works, but not all configs do
[04:59:32] <petev> looks like I need to run make too
[04:59:39] <petev> there is no emc script now
[04:59:45] <SWPadnos_> also, there's no ini file in m5i20/, unless you added it
[04:59:51] <petev> yeah, I saw that
[04:59:57] <petev> the hal files are also bad
[05:00:02] <petev> they have old pin names
[05:00:03] <SWPadnos_> hm - maybe you do need make as well, I'm not sure
[05:00:25] <SWPadnos_> yep - the config stuff isn't really functional yet, it's just reorganized
[05:01:34] <petev> should I fix the hal files?
[05:02:18] <SWPadnos_> sure - that would be grea!
[05:02:23] <SWPadnos_> great, even
[05:02:42] <petev> ok, just didn't want to mess up anything alex was working on
[05:02:52] <petev> I'll fix them and add some ini
[05:02:59] <SWPadnos_> I'm sure it's no problem to fix stuff ;)
[05:03:23] <petev> it was a bit when I wanted to fix emc ;-)
[05:04:19] <petev> should I do full on CL configs?
[05:04:41] <SWPadnos_> not unless it's necessary to get estop to work
[05:04:50] <SWPadnos_> these are only samples, after all
[05:04:55] <petev> that's pretty machine dependant
[05:05:06] <petev> does the spindle brake stuff still work
[05:05:07] <SWPadnos_> right - so I'd leave it out for now
[05:05:16] <SWPadnos_> it can always be added
[05:05:39] <petev> does spindle brake work from IO?
[05:05:41] <SWPadnos_> it should, as far as removingthe brake signal when you ask for the spindle to be on
[05:06:04] <petev> does it still look at the on/off delays from INI?
[05:06:14] <SWPadnos_> I see the correct lights light up on my USC
[05:06:22] <petev> ok
[05:06:32] <SWPadnos_> I don't know about that - you'd have to look for the params in motion or io
[05:06:46] <petev> argh
[05:07:00] <SWPadnos_> I'll take a look - one sec
[05:08:58] <SWPadnos_> I don't see those delay parameters
[05:09:20] <petev> they were called SPINDLE_OFF_WAIT
[05:09:41] <petev> should be in io
[05:09:58] <SWPadnos_> nope - only on/off/up/down/speed/brake, no params for spindle at all
[05:10:20] <petev> well how can it work right without a delay
[05:10:22] <SWPadnos_> and fwd/rev, of course
[05:10:43] <petev> do we need CL for this now then?
[05:10:43] <SWPadnos_> there is a spindle-speed-in, maybe it's expected that you'll use feedback
[05:10:54] <SWPadnos_> I'm not sure
[05:11:02] <petev> the brakes are often air cylinders
[05:11:05] <petev> they are slow
[05:11:18] <SWPadnos_> I'd wait on that - we want to define some standard signal names to use in the configs
[05:11:32] <SWPadnos_> that may be less confusing for tech support
[05:11:42] <petev> hmm, it's going to be pretty broken without delays
[05:12:04] <SWPadnos_> it won't be able to run a machine, but it will be a starting point for something that can
[05:12:30] <petev> yeah, but you know people will try and run it
[05:12:38] <petev> and they won't know what to do with CL
[05:13:01] <SWPadnos_> they have to edit, or the pins won't be properly connected for their IO
[05:13:23] <SWPadnos_> especially with the m5i20, where any pin can really be anything
[05:13:49] <petev> no, I think we just need to route the spindle fwd/rev and brake through CL and add delays
[05:13:56] <petev> or something like that
[05:14:24] <petev> not that I'm a ladder expert
[05:14:29] <SWPadnos_> that's probably true, btu I'd wait until we have standard names, then we can add basically the same .clp to every dir that needs them
[05:15:01] <petev> ok, maybe we need a common/machine.clp or something
[05:15:13] <SWPadnos_> the other thing is that you can include hal files from elsewhere, so you can have a HALFILE named ../cl/spindle.clp
[05:15:15] <SWPadnos_> yes
[05:15:29] <SWPadnos_> there could even be subdirs in common/cl/
[05:15:38] <petev> yep
[05:15:41] <SWPadnos_> though you can only load one ladder per instance of CL< right?
[05:16:07] <petev> yes
[05:16:28] <petev> I'll add some lines in HAL but leave them commented
[05:16:43] <SWPadnos_> ok
[05:35:35] <SWPadnos_> see ya later - it's bedtime for me
[05:35:41] <petev> gnight
[05:36:51] <SWPadnos_> SWPadnos_ is now known as SWP_Away
[12:18:35] <rayh> logger_devel: bookmark
[12:18:35] <rayh> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2005-12-15#T12-18-35
[13:23:31] <rayh> I was working on the ppmc but disconnected some net stuff.
[14:23:06] <cradek> rayh: your connection seems worse than usual lately
[14:24:43] <rayh> I think that was me.
[14:25:08] <rayh> Was messing with cables trying to get a 4th computer into the system.
[14:25:36] <cradek> ah
[14:33:16] <rayh> rayh is now known as rayh_away
[16:20:03] <rayh_> Well I've got univstep running again. I get following errors with the current checkout.
[16:20:32] <rayh_> so this includes the new 24 ->32 change.
[16:21:00] <rayh_> I believe. Let me make certain.
[16:22:23] <rayh_> # $Revision: 1.20 $
[16:22:23] <rayh_> * $Author: cradek $
[16:22:24] <rayh_> * $Date: 2005/12/15 02:13:07 $
[16:22:33] <rayh_> so this is the current version.
[16:22:45] <cradek> so like SWP said, that wasn't the problem
[16:23:00] <rayh_> seems so.
[16:23:24] <rayh_> we were talking about taking the derivitive of comand and encoder and plotting them with fe.
[16:24:01] <rayh_> let me see if I can set that up.
[16:24:06] <rayh_> I may need help.
[16:34:14] <SWP_Away> SWP_Away is now known as SWPadnos_
[16:34:24] <SWPadnos_> hi there
[17:06:12] <rayh_> Hey guys. I've raised the ferror to 1.0 and watching the travel.
[17:06:34] <rayh_> I'm not seeing any of the big excursions like I did yesterday.
[17:06:45] <SWPadnos_> cool
[17:06:47] <cradek> what is different?
[17:06:47] <rayh_> will go back and run that version and see if I get them there.
[17:07:03] <SWPadnos_> one thing I considered is pid deadband
[17:07:30] <rayh_> there is such a thing?
[17:07:39] <SWPadnos_> the feedrate of cds is 16, so at 4000 steps/inch, you get 240ksteps/second, or 240 per servo cycle
[17:07:53] <SWPadnos_> and the error was around 240 (or 256)
[17:08:04] <SWPadnos_> yes, there is pid.n.deadband
[17:08:33] <rayh_> Okay. That is what the ini names deadband also?
[17:08:38] <SWPadnos_> and I think the pid outout swings instantly to 0 if you get below the deadband
[17:08:49] <SWPadnos_> I think so (in your config, it tried to load it)
[17:09:00] <rayh_> I did a series of really shallow tapers
[17:09:21] <rayh_> and you can watch fe increase to the next step pulse.
[17:09:30] <SWPadnos_> right
[17:09:50] <rayh_> nice clean sawtooth waveform.
[17:10:10] <rayh_> If there was just a bit of rake on it we could cut wood.
[17:10:22] <SWPadnos_> heh
[17:10:48] <rayh_> It looks to me like we only get one following error setpoint.
[17:11:25] <SWPadnos_> that could be, though jmk said he didn't change much in the TP, other than connecting it to HAL
[17:12:43] <rayh_> I'll have to ask him.
[17:12:58] <SWPadnos_> one thing I noticed in your config - the stepgen max_output is the same as the TP max_output. there's no headroom
[17:13:05] <SWPadnos_> (or pid.maxoutput)
[17:13:15] <rayh_> going to test again with yesterday's build
[17:13:39] <SWPadnos_> also, there's no place to put a STEPGEN_MAXACCEL
[17:13:49] <SWPadnos_> only a STEPGEN (or PID) MAX_VEL