#linuxcnc-devel Logs

Mar 07 2020

05:27 AM andypugh: jepler: Probably not around yet?
05:31 AM andypugh: Dewey fixed the kins problem, but I don’t understand why there was a problem.
05:31 AM andypugh: https://github.com/LinuxCNC/linuxcnc/commit/ef6f36a16c7789af258d34adf4840d965f4c0b10
10:48 AM cerna: andypugh: Yeah, I expected that to be the case. However, I think that the lowest case is also of interest. (I really just care about the motion [+ kins, but kins components have no execution thread, as far as I know].) I know somebody here was running it 500Hz. Maybe it could be scaled even lower.
10:53 AM pcw_home: I know our hardware only goes down to about 200 Hz currently due to DPLL range limits
11:26 AM cerna: pcw_home: And on 200Hz the motion component (or parts which consists the *CNC in LinuxCNC) worked without issues?
12:02 PM pcw_home: well except that chord errors are roughly proportional to the square of the period in PVT systems
12:05 PM pcw_home: though theoretically with the right interface hardware/drives LinuxCNC could do PVAT
12:07 PM cerna: PVAT == Position, Velocity, Acceleration, Time ?
12:11 PM pcw_home: yes, as you add more derivatives to the waypoint information you get lower errors on curves between waypoints so lower sample rates become possible with the same error budget
12:12 PM pcw_home: (ignoring feedback issues)
12:43 PM jepler: andypugh: local variables must be initialized before use, otherwise the behavior is undefined. I guess in this case the kernel defined the behavior as "crash, everytime", which is a surprise to me as well. It seems like one of the ={0} and the for loop that were added must be redundant, but it doesn't hurt I guess. Assuming this worked for you, I'm glad dgarr found the fix to make
05:30 PM skunkworks: cerna: I am running the servo loop at 500hz and am seeing less than .0001" followning errors
05:31 PM skunkworks: but that is also using mesa and dpll
07:21 PM skunkworks: http://electronicsam.com/images/greenmachine/2020-03-07-191256_1920x1080_scrot.png
07:29 PM skunkworks: https://pastebin.com/Khsrh9TH
07:29 PM skunkworks: WIP
07:30 PM skunkworks: andypugh: ^
07:41 PM andypugh: jepler: But ={0} surely is initiailisation?
08:31 PM jepler: andypugh: oh in that case I can't read diffs and don't understand the fix either
08:33 PM andypugh: I don’t trust a fix we can’t explain
08:47 PM skunkworks: andypugh: https://youtu.be/xv9N-hqgvEg
08:47 PM andypugh: Curious to see what you get
08:47 PM skunkworks: yes - me too.
08:48 PM skunkworks: interesting experiment.
08:48 PM skunkworks: might look just fine in wood or plastic
08:50 PM skunkworks: stupid question.. when you first bring a machine up the encoder postion is based on where ever it was sitting? You would have to run an index enable to get the encoder to reset to index and then from that point on - the spindle postion should always be based on the the index. right?
08:51 PM andypugh: Yes,
08:52 PM andypugh: In fact my whole multi-soindle thng was a precursor to making spindles home like axes. Which hasn’t happened yet.
08:52 PM andypugh: Going to bed, but will leave this open
08:54 PM skunkworks: Night!