#linuxcnc-devel Logs

Nov 02 2017

12:16 AM tjtr33: dgarr if you are interested https://imagebin.ca/v/3frrI98WN9qH https://imagebin.ca/v/3frs3I7c0Ysw https://imagebin.ca/v/3frsYCW3vqbe https://imagebin.ca/v/3frtwzuFx7ep
12:17 AM tjtr33: it works, it is simple, maybe of use to someone
12:21 PM seb_kuzminsky: tjtr33: those toolpaths are cool
12:21 PM seb_kuzminsky: how does the external-offsets branch handle the commanded feed? noticed any issues?
12:22 PM seb_kuzminsky: my understanding is that external offsets get applied at a constant speed (and accel) set by the ini file, does that match your observations?
12:22 PM seb_kuzminsky: (my understanding may well be wrong, i haven't read the code at all, just the docs)
12:23 PM tjtr33: i had quite a few hangs, where linuxcnc went unresponsive, but have not blamed linuxcnc, maybe what i asked for ;-)
12:23 PM tjtr33: i dont know what dewey added the ability to change the ini file accell and velocity.
12:24 PM archivist: I looked and though of how it is not in direct phase with the gcode so would still use gcode for that
12:24 PM tjtr33: i know there is a strong relation between the optimum chip load ( overlap of circles ) and the programmed velocity.
12:25 PM tjtr33: i used very low feedrates to accomodate.
12:26 PM tjtr33: i can post the code used somewhere, but was adding code to step the radius ( aka hgt in the original work by dewey) to a new value right now
12:27 PM seb_kuzminsky: hmm, hangs and unresponsive linuxcnc sounds super worrying to me
12:27 PM seb_kuzminsky: can you reproduce it reliably by just poking the extoffset pins?
12:27 PM tjtr33: the good part is it just follows the gcode path
12:28 PM tjtr33: the hangs may well be that i asked for stupid things in my parameters. i am still trying to understand the workings
12:28 PM seb_kuzminsky: linuxcnc should be robust against stupid requests...
12:29 PM tjtr33: i can reproduce those drawings and more, a very careful litany of when to do what...
12:29 PM seb_kuzminsky: if you can reliably make linuxcnc misbehave, then i ask that you open an issue for it on the github issue tracker
12:29 PM seb_kuzminsky: https://github.com/linuxcnc/linuxcnc/issues
12:30 PM tjtr33: well stupid like... i asked the sin & cosine genrators for values above 1.000 and got squared circles, making me thing i overstepped the natural bounds
12:30 PM seb_kuzminsky: and that cause linuxcnc to become unresponsive?
12:31 PM tjtr33: i can reproduce bad results also , bt was having fun the other way.
12:31 PM tjtr33: yes, i could move the screen and 'wipe off' the content., jiggle it and get zigzags
12:31 PM seb_kuzminsky: that's not supposed to happen
12:32 PM tjtr33: the linuxcnc window ( no t screen)
12:32 PM seb_kuzminsky: right
12:32 PM seb_kuzminsky: which gui?
12:32 PM tjtr33: axis
12:32 PM tjtr33: what i did is barely differnt from what dewey did, did you se the dia-gram?
12:33 PM tjtr33: (made in dia, almost same as dewey's)
12:33 PM seb_kuzminsky: this one? https://ibin.co/3frtwzuFx7ep.png
12:33 PM tjtr33: yep
12:34 PM seb_kuzminsky: when you say you asked the sin/cos generators in siggen for values above 1.000, do you mean you set the amplitude input to a value greater than 1.000?
12:35 PM tjtr33: yes
12:35 PM seb_kuzminsky: i ran siggen with an amplitude > 1 just the other day and it ran fine
12:35 PM seb_kuzminsky: it certainly didn't cause axis to stop updating
12:35 PM seb_kuzminsky: something more complicated must be going on
12:36 PM seb_kuzminsky: in fact we have a test that runs siggen with an amplitude of 1.002 ;-)
12:37 PM tjtr33: i think soemone else should try what i did, so i'll begin the github issue tracker
12:37 PM seb_kuzminsky: thanks!
12:37 PM tjtr33: sorry if i didnt respond earlier , my systems just came back up from a citywide brownout
12:38 PM seb_kuzminsky: no worries
12:38 PM seb_kuzminsky: glad you got you power back
12:39 PM tjtr33: hey i will begin tomorrow, the missus just told me it was midnight. i will work on it in the am, i also see it could be used for sizing bores and engine turning, slotting and other apps.
12:40 PM tjtr33: im 12-13 hrs in the future :-)
12:40 PM seb_kuzminsky: we're all trying to catch up with you :-)
02:28 PM JT-Shop: do you need to flash a 6i25 with firmware?
02:31 PM JT-Shop: hmm I found parallel/5i24.zip I assume it's the same for the 6i24
02:37 PM JT-Shop: pcw_mesa: ok I see to use mesaflash, what bit file would be for a 7i48, 7i37TA and 7i44?
02:43 PM pcw_mesa: 6I24/5I24 -16 would probably be be 5i24_16_svss6_8.bit
02:44 PM JT-Shop: thanks
02:46 PM pcw_mesa: Yeah that it, 7I48 on 0..23 7I37 on 24..47 7I44 on 48..71
02:46 PM pcw_mesa: I should make the .pin files, I had to look up the source
03:01 PM JT-Shop: oh yea the link on the 6i24-16 page is a 404, guessing it should be http://www.mesanet.com/software/parallel/5i24.zip instead of 6i24.zip
03:07 PM JT-Shop: hmm, I get Checking file... Invalid bitfile header
03:42 PM andypugh: Is anyone in touch with Machinekit? I suspect that the remapping query on the mailing list today is only likely to get answered there. If remap really does re-load the previous G-code file that sounds like quite a bug.
04:01 PM JT-Shop: pcw_mesa: I tried two different bit files like sudo mesaflash --device 5I24 --write 5i24_16_svss6_8.bit
04:02 PM JT-Shop: I get Checking file... Invalid bitfile header!
04:34 PM cradek: andypugh: I agree with your response
04:43 PM cradek: he might be doing a weird thing in his remap, and yeah debugging should start there...
05:17 PM pcw_mesa: JT-Shop is that the latest mesaflash? ISTR that there was a bug with 5I24 sizes
05:18 PM JT-Shop: might not be the latest, can you get a version from the command line?
05:18 PM JT-Shop: version 3.2.0
05:25 PM jepler: hm is the pci access bug that affects modern platforms not in 3.2.1?
05:25 PM jepler: h$ git log --oneline v3.2.1..v3.3.0-pre0 | grep memcpy
05:25 PM jepler: b60c5a2 pci: Cannot use memcpy() for PCI accesses
05:26 PM jepler: I see linuxcnc.org ships 3.3.0~pre0 for debian stretch amd64, dunno about other platforms
05:29 PM jepler: (but the pathology of that problem, according to the commit message, is Failed to write valid boot sector)
05:31 PM jepler: what's this print? It should start "0000000 00 09": od -tx1 -N8 yourfile.bit
05:37 PM JT-Shop: upgrading now
05:43 PM JT-Shop: 0000000 00 00 00 00 00 00 00 00
05:45 PM JT-Shop: pcw_mesa: I have version 3.3.0~pre June 28 2017 and still get the Checking file... Invalid bitfile header!
05:45 PM JT-Shop: jepler: all 0's on first line second line 0000010
05:47 PM pcw_mesa: Let me try here and see what I get
05:48 PM JT-Shop: ok
05:53 PM pcw_mesa: hmm works for me
05:53 PM pcw_mesa: what does:
05:53 PM pcw_mesa: sudo mesaflash --device 5i24 --readhmid print?
05:54 PM JT-Shop: PCI device at 0000:02:00.0
05:54 PM JT-Shop: oh forgot readhmid
05:55 PM JT-Shop: I get all 71 pins
05:55 PM JT-Shop: or 72 even
05:55 PM pcw_mesa: what size FPGA does it show?
05:56 PM JT-Shop: 16 KGates
05:59 PM pcw_mesa: so if I do
05:59 PM pcw_mesa: sudo mesaflash --device 5i24 --write 5i24_16_svss6_8.bit
05:59 PM pcw_mesa: it works fine
06:00 PM pcw_mesa: thats mesaflash 3.2.0 on a 32 bit system
06:02 PM JT-Shop: I have 3.3.0~pre now on that pc
06:02 PM JT-Shop: I still get invalid bitfile header, could the bit file be corrupt?
06:05 PM JT-Shop: yup bad bit file...
06:05 PM pcw_mesa: whats md5 5i24_16_svss6_8.bit print?
06:06 PM JT-Shop: I downloaded directly into that PC from mesa and now it flashes
06:06 PM pcw_mesa: sorry md5sum 5i24_16_svss6_8.bit
06:06 PM pcw_mesa: weird
06:07 PM pcw_mesa: at least mesaflash didn't program the 6I24 with bithash
06:07 PM JT-Shop: I d/l in windoze to my NAS and copied it to my linux pc
06:08 PM pcw_mesa: probably has a virus inserted :-)
06:08 PM JT-Shop: last bit of the md5sum is 17f05
06:08 PM JT-Shop: lol
06:08 PM pcw_mesa: yep thats what I get from a working file
06:09 PM JT-Shop: chicken time!
06:09 PM JT-Shop: thanks for the help
06:09 PM pcw_mesa: no problem
06:47 PM andypugh: pcw_mesa: I think my 7i84 crashed today. encoder 0 was counting normally. Encoder 0 less so. It meant that my feed control knob was uselessly random. Rebooting fixed it.
06:50 PM andypugh: https://www.youtube.com/watch?v=gPKnczIoS3c
06:50 PM andypugh: This is (until the end) me just turning the knob slowly clockwise
06:51 PM andypugh: What it looks most like, but not exactly like, is what you get with bit reversal.
06:51 PM andypugh: (Not that I expect that we will ever figure out what happened)
07:00 PM pcw_mesa: I dont think Ive seen such an issue (and the same code is used on the 7I77 and 7I76 encoders)
07:01 PM pcw_mesa: MPG encoders I mean
07:04 PM andypugh: It was not such a problem for my feed override, though I wouldn’t have wanted it on an axis jog.
07:04 PM andypugh: (it’s also possible that the issue is in my code)
07:04 PM pcw_mesa: If it happens again I would try restarting linuxcnc without power cycling the 7I84 (if that cures it it points to the LinuxCNC side)
07:05 PM andypugh: Good point.
07:05 PM pcw_mesa: if only power cycling the 7I84 fixes it that very likely a 7I84 bug
07:06 PM pcw_mesa: We just fixed a minor and unrelated 7I84 bug (7I84 is OK with only one fileld power on)
07:08 PM pcw_mesa: and added optional firmware that allows startup/running without field power
07:09 PM pcw_mesa: ( you set the input thresholds for the A/B sides with hal pins )
10:07 PM Tom_L: using backlash compensation, is the first part of a move a rapid for the compensation then normal feeds?
10:11 PM jepler: yes, backlash compensation happens at the same rate regardless of the motion type (rapid vs feed), but it is still capped to something proportional to inifile maxvel, maxaccel. the exact details don't seem to be documented.
10:13 PM Tom_L: stepgen_maxaccel needs to be greater than max_acceleration by a factor of 1.5 - 2
10:13 PM Tom_L: can you explain that?
10:14 PM Tom_L: when i make a move in a direction sometimes it skips some steps but if i make a move in the same direction again, it's ok
10:14 PM Tom_L: would this be because max_acceleration is set too high?
10:15 PM Tom_L: and the comp is trying to move at a faster rate than the programmed feed
11:24 PM skunksleep: Tom_L: backlash is applied at Max acceleration for the given a is. So worse case scenario is that axis could see 2x acceleration.
11:24 PM skunksleep: Motion + backlash
11:25 PM skunksleep: * given axis