Back
[07:07:12] <skunkworks> pcw_home, different powersupply worked
[07:55:51] <skunkworks> pcw_home, this is with a scale of 10000... I think I maybe need to try averaging over 3 itteratioins likt the wiki mentions..
[07:56:00] <skunkworks> http://imagebin.org/310401
[08:09:49] <skunkworks> (that is rolling average over 20 samples
[09:14:56] <skunkworks> although doing with internal velocity doesn't have that blip
[09:47:28] <archivist> that reminds me of something andy said on the mailing list, check order of comps in the hal file because they effect when they are calculated (using a result from a previous cycle)
[09:48:30] <archivist> although a dependency sort on load would get rid of that problem, give a warning
[10:06:05] <pcw_home> I looked pretty carefully at the blip and and am convinced that not much
[10:06:06] <pcw_home> that can be done about it
[10:06:08] <pcw_home> (the velocity estimator is doing the best it can with no information)
[10:06:09] <pcw_home> If i know that there is a reversal (like you have in your plot)
[10:06:11] <pcw_home> it can be fixed but this make the estimation worse on a stop
[10:07:46] <pcw_home> set the scale higher and the blip will be smaller...
[10:08:36] <pcw_home> probably the reason Fanuc uses 16M count encoders on current drives
[10:08:51] <pcw_home> (velocity estimation)
[10:11:22] <skunkworks> pcw_home, I think all you need is to be able to look into the future.... Are you working on that?
[10:14:17] <archivist> look for the crystal ball comp in the hal manual :)
[10:17:01] <pcw_home> yeah the clairvoyant option
[10:18:14] <pcw_home> or run the average on the accel as well
[10:19:10] <pcw_home> (that would also equalize the delays)
[10:19:28] <skunkworks> oh - hmm
[10:19:41] <skunkworks> 20k steps/inch didn't help much
[10:20:20] <pcw_home> try 200K
[10:21:15] <archivist> has the velocity estimation got filtering
[10:21:56] <pcw_home> not normally because you done want any delay
[10:21:56] <skunkworks> hmm - can I do 200k?
[10:22:19] <archivist> pcw_home, that was what I was expecting
[10:22:46] <pcw_home> with a hardware stepgen
[10:25:24] <pcw_home> (thats only 400 KHz)
[10:25:50] <skunkworks> well - setting the step space/len to 10us - the encoder doesn't seem to read
[10:26:04] <skunkworks> (and 200k)
[10:26:33] <skunkworks> encoder counter
[10:27:31] <pcw_home> 200 KHZ is well within the range of the encoder counter (unless the sample frequency has been messed with)
[10:28:22] <pcw_home> wait a sec for 400 KHZ you need to set steplen and space to ~1 usec
[10:29:04] <pcw_home> 10u nd 10u is 50 KHz max
[10:34:49] <malcom2O73> Oh man, I've stepped down the rabbit hole of hal file editing :/ heh
[11:53:37] <skunkworks> http://imagebin.org/310467
[11:53:52] <skunkworks> so - I switched to quadature (input scale at 200k
[11:54:15] <skunkworks> now - the encoder scale on the reading computer needed to be set to 800k...
[11:54:55] <skunkworks> so the manual is true? every 'step' is one complete quadature cycle?
[12:00:09] <pcw_home> yes (but just scaling wise)
[12:00:35] <pcw_home> the quadrature is output uniformly
[12:01:18] <pcw_home> step/dir should work as well if you set the steptime and stepspace appropriately
[12:03:19] <pcw_home> thats 400 KHz full scale velocity so needs ~1 usec steptime and stepspace to no be limited by the stepgen
[12:07:08] <pcw_home> so even for quadrature mode you should set the steptime and stepspace to minimal values
[12:07:09] <pcw_home> (since the hardeware still obeys these limits regardless of mode)
[12:13:00] <skunkworks> I will have to re-visit it. I wasn't getting any movement with step/dir set to 200k
[12:13:48] <skunkworks> linuxcnc does scold you when you don't have the timing set sanely
[12:14:07] <pcw_home> no but following error will
[12:14:36] <pcw_home> for quadrature I would set steplen and stepspace to say 100 ns
[12:14:53] <skunkworks> I think that is what I have it set to :)
[12:15:07] <skunkworks> pretty trace :)
[12:15:11] <pcw_home> (the drive should probably do this but I doubt that it does)
[12:15:22] <pcw_home> driver
[12:16:34] <pcw_home> yeah the glitch is really just the velocity estimation doing the best guess it can when it stops getting information
[12:22:04] <pcw_home> you need the delay component to align the traces
[12:23:43] <skunkworks> the traces are only off by 20ms...
[12:24:16] <skunkworks> (averaging over 20ms)
[12:24:23] <skunkworks> *20 samples
[12:25:17] <pcw_home> setp delay 20
[12:33:34] <skunkworks> as good as our old b&k would display traces.. ;)
[12:34:24] <skunkworks> you would think there would already be something like that.
[12:34:42] <pcw_home> delay would probably be useful for extruders also
[12:36:22] <pcw_home> to (look ahead)
[12:38:27] <pcw_home> now if motion looped back its position commands then arbitrary amounts of lookahead could be available in hal for special apps
[14:12:40] <KGB-linuxcnc> 03Norbert Schechner 052.6 bc8a9f1 06linuxcnc Merge branch '2.6' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc8a9f1
[14:12:40] <KGB-linuxcnc> 03Norbert Schechner 052.6 e0f43b5 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_5 - allow hide axis 4 ; set DRO size * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e0f43b5
[14:38:41] <KGB-linuxcnc> 03Chris Radek 052.6 53339d2 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=53339d2
[14:40:05] <malcom2073> andypugh: Thanks for pointing me in the direction of that machinekit thread about velocity based extrusion. It looks like that'll be the way to go, but I have to wait until I get my BBB cape and switch over to machinekit. I can't for the life of me get their HAL file working (doesn't help that today is the first day I've even lookd at the hal stuff)
[14:40:33] <malcom2073> working on a parallel port based PC I mean
[14:40:40] <malcom2073> is there a good writeup about HAL somewhere?
[14:41:39] <andypugh> See the HAL links here:
http://www.linuxcnc.org/docs/html/
[14:42:32] <KGB-linuxcnc> 03Norbert Schechner 052.6 6d314ae 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_5 - allow hide axis 4 ; set DRO size * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6d314ae
[14:42:37] <malcom2073> Ok, that's the one I was looking at
[14:42:47] <malcom2073> I'll keep on, see if I can get it before the cape gets here
[14:43:26] <andypugh> intro + tutorial should be enough.
[14:44:09] <andypugh> Just remember net signal pin (pin, pin, pin) and that every signal can only be netted to one output pin. Signals can appear in more than one net line, pins can’t.
[14:44:36] <malcom2073> ok
[14:44:55] <malcom2073> The main thing is trying to weed out the BBB PRU pins, and put in parallel port pins
[16:39:39] <seb_kuzminsky> is git.linuxcnc.org down?
[16:39:44] <seb_kuzminsky> 0 15:20:05 seb@steel /home/seb/linuxcnc.git/src> git fetch origin
[16:39:45] <seb_kuzminsky> ssh: connect to host git.linuxcnc.org port 22: Connection timed out
[16:39:45] <seb_kuzminsky> fatal: The remote end hung up unexpectedly
[16:42:57] <micges> seb_kuzminsky: * cradek has quit (Quit: rebooting for updates...)
[17:25:22] <KGB-linuxcnc> 03Chris Radek 05master 4efd80d 06linuxcnc Merge branch '2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4efd80d