Back
[07:46:14] <skunkworks> pcw_home, changed to pid stepgen - same issue. here is mach...
http://imagebin.org/303147
[07:46:17] <skunkworks> same thing
[07:46:59] <skunkworks> if I do the same thing in sim velocity -> moveavg -> ddt - I don't get the spikes like that.
[07:49:43] <skunkworks> almost points to a velocity esitmation issue at low velocites - doesn't it?
[08:02:15] <CaptHindsight> the 3.4 RTAI kernel doesn't seem to work with Kubuntu 10.04, no use keyboard/mouse at login, the old 2.6 is fine
[08:02:32] <CaptHindsight> use/usb
[09:07:03] <pcw_home> skunkworks: can you try a hardware stepgen?
[09:07:40] <skunkworks> If running the 7i80 -> 7i80 would be a decent test...
[09:07:47] <pcw_home> or slow the sine wave down by a factor of 4 or so
[09:08:02] <pcw_home> so its easier to see whats happening
[09:11:26] <CaptHindsight> what's a good simple way to stop Linuxcnc from running a program? Let's say Linuxcnc can run but just not RUN G-code without an additional password or something
[09:12:48] <seb_kuzminsky> that's a strange thing to want
[09:13:17] <seb_kuzminsky> you could write a comp that drives an output bit False until you type in a password, and use that bit in your estop chain?
[09:14:19] <CaptHindsight> yes, someone asked about remote authorization
[09:15:01] <CaptHindsight> the system can run,just not run G-code without a password or external authorization
[09:15:23] <CaptHindsight> and also count the number of runs, say only allow 5 or 10 runs of a part
[09:16:25] <seb_kuzminsky> i've got my doubts about this
[09:16:25] <CaptHindsight> like a video a game or cable box, you can only run what you're authorized to run
[09:16:45] <seb_kuzminsky> what if you break a tool and have to restart the program?
[09:17:28] <CaptHindsight> you'd have to ask for an extra/new run
[09:17:41] <CaptHindsight> and prove that the tool broke
[09:17:58] <CaptHindsight> I just need to demo something simple
[09:18:19] <CaptHindsight> for all I know they will rewrite and support secure Linuxcnc
[09:19:57] <CaptHindsight> they are even asking for a camera to record each part at the end of the runs
[09:20:51] <seb_kuzminsky> i think there's a pin coming out of motion that tells you when it's done running a program, you could net that pin to a pulse counter, and estop the machine after the requested number of counts
[09:21:09] <seb_kuzminsky> anyone with shell access to the machine could run halcmd and rewire this lock-out circuit
[09:21:32] <CaptHindsight> good enough for a demo
[09:23:02] <CaptHindsight> they like Linuxcnc, but they also want to lock it down
[09:24:05] <skunkworks> that seems counter intuitive...
[09:24:08] <skunkworks> ;)
[09:24:26] <CaptHindsight> yeah
[09:24:44] <CaptHindsight> like using Linux on a cable box
[09:37:31] <skunkworks> pcw_home, this is 25% feed
[09:37:32] <skunkworks> http://imagebin.org/303164
[09:37:48] <skunkworks> http://imagebin.org/303165
[09:38:05] <skunkworks> is it just that the scale is too low to get a decent velocity estimate?
[09:38:34] <skunkworks> across zero
[09:39:09] <pcw_home> I think so, velocity estimation always goes bad near 0
[09:41:02] <pcw_home> can you sample the step pulse? (it will be aliased but should be ok around zero crossing)
[09:41:28] <skunkworks> can I look at the gpio pin?
[09:41:37] <pcw_home> sure
[09:42:08] <pcw_home> or the stepgen step pin
[09:42:17] <pcw_home> or the signal
[09:46:41] <pcw_home> another funny thing happens at velocity 0 crossings, in the bad zone there are maybe 10 samples with no new data
[09:46:42] <pcw_home> and there is no way for the encoder hardware/software to know where the reversal occurred so messes up
[11:06:06] <skunkworks> sorry - work
[11:06:15] <skunkworks> :_
[11:22:14] <KGB-linuxcnc> 03Norbert Schechner 05master 1bb1c45 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1 - corrected release number, final vor release! * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1bb1c45
[11:35:50] <skunkworks> I could graph counts
[11:37:59] <pcw_home> A and B in quadrature mode would be the best
[11:41:30] <skunkworks> I could do that..
[11:41:38] <skunkworks> then graph a and b?
[11:43:21] <pcw_home> just to see what the encoder has to work with
[11:44:14] <pcw_home> (though I suspect you just need to increase the scale so you dont have 3 KHZ full scale step rate)
[11:48:38] <pcw_home> the encoder code has no choice but to set the estimated velocity to 0 on the
[11:48:39] <pcw_home> first count after a reversal since it cannot know when the reversal occurred
[11:48:41] <pcw_home> so could report a near infinite velocity (~0 time between counts in each direction)
[11:50:24] <skunkworks> linuxcnc is cool
[11:50:25] <skunkworks> http://imagebin.org/303189
[11:50:45] <pcw_home> this is another way of saying, the encoder counter needs 2 counts in the new direction before it can register a new velocity
[11:52:02] <pcw_home> and you can see that in the plot!
[11:53:03] <skunkworks> so making the scale larger would help that problem (like 10 times probably...)
[11:53:14] <pcw_home> Yep
[11:53:53] <skunkworks> well that sucks (well - I guess a faster computer (lower latency) I could probably get a bit faster..
[11:55:40] <pcw_home> 3 KHz max is pretty slow (90RPM in a gecko)
[12:00:36] <pcw_home> (well maybe it only gets that fast on the sine due to accel limits or something)