#linuxcnc-devel Logs

Mar 06 2020

01:28 AM CMorley: I agree with cerna we need more developers before linuxcnc dies
01:48 PM CMorley: linuxcnc-build: force build --branch=2.8 0000.checkin
01:48 PM linuxcnc-build: The build has been queued, I'll give a shout when it starts
01:49 PM CMorley: buildbot is stalled :(
02:45 PM andypugh: Git exper needed
02:46 PM andypugh: jepler live?
02:46 PM jepler: andypugh: hey
02:46 PM andypugh: andypugh@rm-one:~/linuxcnc-dev$ git bisect good
02:47 PM andypugh: There are only 'skip'ped commits left to test.
02:47 PM andypugh: The first bad commit could be any of:
02:47 PM andypugh: 582ad8f592b80ec7c0c058313d5fa31182dfddef
02:47 PM andypugh: 1b44b21219552067212d32241376bc1bdd15816d
02:47 PM andypugh: 8ec2f781b5a4b19270fc38b5d5f9d412a7ba9138
02:47 PM andypugh: 10ae352190d13b60a2153b5284c5cda7d7de59a9
02:47 PM andypugh: b2e2a6ad3999c1aba0c75b6f3a98032b8900c381
02:47 PM andypugh: 5a907fe354f663ea583286822695e3906fa4a83a
02:47 PM andypugh: We cannot bisect more!
02:47 PM jepler: what issue are you investigating?
02:47 PM andypugh: 2.9 crashes when running the linuxcnc script with the RTAI kernel
02:48 PM andypugh: halrun and latency test are fine
02:48 PM andypugh: 2.8 is fine
02:48 PM jepler: hard crash -- no other troubleshooting e.g. dmesg?
02:48 PM andypugh: complete lock-up
02:49 PM andypugh: nothing in tail -f /var/lor/kern-log
02:49 PM jepler: uspace fine?
02:49 PM andypugh: As far as I know. Lots of people are using master
02:50 PM andypugh: (And I suspect that some are maybe using the 4.x.148 RTAI kernel with master too, but it has a problem for me.
02:50 PM andypugh: This is with debian Buster
02:50 PM jepler: any old configuration files (e.g., simaxis)?
02:50 PM jepler: what led to skipping so many refs?
02:51 PM andypugh: I have been running sim/touchy
02:51 PM andypugh: I skipped ones that didn’t build
02:51 PM jepler: were the not building for the same/similar reason, or all different reasons?
02:51 PM andypugh: At least 3, maybe 4, failed to find plasmac.comp
02:52 PM andypugh: I suspect the next step is to make those hashes compile and test them individually
02:55 PM jepler: seems like of the realtime code affected by those skipped commits, it is most likely to be the kinematics changes
02:55 PM andypugh: https://paste.ubuntu.com/p/yCPm3jsV6Q/
02:55 PM andypugh: makes sense
02:56 PM andypugh: As I have not experimented with loading a kins in halrun
02:58 PM jepler: you might try loadrt trivkins just in a halrun then,
02:59 PM andypugh: all fine
02:59 PM andypugh: But then it needs motion to call the kins for anythign to happen, I guess
03:00 PM andypugh: But, also, I need to actually compile linuxcnc with a not-good state, don’t I ? :-)
03:00 PM andypugh: (last was git bisect good )
03:00 PM jepler: could be any of those things. looks like the new map_coordinates_to_jnumbers is called from trivkins' rtapi_app_main
03:01 PM andypugh: I was wondering about the pi stuff. But I imagine that is only actually run when called?
03:02 PM andypugh: There is no attempt do do pi-ish things on x86?
03:02 PM jepler: shouldn't be, but you never know once your bug gets sufficiently weird
03:03 PM andypugh: I suppose wierd bugs are more fun than embarassing bugs.
03:04 PM andypugh: well, there you go
03:04 PM andypugh: halrun, loadrt trivkins….. broken pipe
03:05 PM andypugh: Now I need to walk upstaris and pres the power button.
03:06 PM andypugh: Oh, and now back up again to launch wpa_supplicant…. I really ought to sort that out.
03:11 PM andypugh: Looking at the commit, https://github.com/LinuxCNC/linuxcnc/commit/1b44b21219552067212d32241376bc1bdd15816d my first thought is a macro-clash with ALLOW_DUPLICATES ? Likely?
03:13 PM andypugh: Not lookling likely, really.
03:17 PM jepler: I can't spot any problem with the code just by looking or by running it on uspace
03:18 PM jepler: including with valgrind, ubsan, and addrsan
03:18 PM andypugh: Do you feel inclined to try with RTAI?
03:19 PM andypugh: I am curious whether it’s a purely “my PC” issue
03:26 PM jepler: no, or at any rate I don't feel like I have the time right now
03:26 PM andypugh: Entirely fair
03:26 PM jepler: good luck and ttyl
03:27 PM jepler: btw thanks for showing the git bisect log, that helped me be confident I was looking at the right refs, etc.
03:28 PM jepler: one last thing to narrow down the commits: I think if you revert b2e2a6ad3999c1aba0c75b6f3a98032b8900c381 and 1b44b21219552067212d32241376bc1bdd15816d it should build and if it does you can confirm if it fixes the problem.
03:29 PM jepler: that code, I didn't spot any specific problem but it has arrays and pointers and strings and so I could sure screw it up if I wrote it :)
03:30 PM andypugh: Well, the commit immediately prior to 1b44 seems fine
03:35 PM pcw_mesa: Andypugh: I think I figured out at least a bit about the halshow bug
03:35 PM andypugh: Hmm?
03:36 PM pcw_mesa: I think it trips up if there are pins and parameters with the same name
03:39 PM pcw_mesa: And the 7I87 triggers some oddness in the sserial driver with GDT parameters so you end up with parameters with the same name as pins
03:40 PM pcw_mesa: I think long term I will change the public GDT on the 7I87 so it doesnt have so many duplicate GDT entries
03:41 PM pcw_mesa: but it would be nice to figure out why halshow cant distinguish between pins and parameters of the same name
03:42 PM andypugh: Well, HAL can’t tell the difference.
03:42 PM andypugh: What would “setp” do?
03:42 PM andypugh: (ditto “getp”)
03:43 PM pcw_mesa: net works of course
03:43 PM pcw_mesa: halcmd show pin works
03:43 PM pcw_mesa: halscope works
03:44 PM andypugh: Yes, as there is a “pin” in there to disambiguate
03:44 PM pcw_mesa: theres a "pin" in halshow also but it doesnt work
03:45 PM pcw_mesa: that is you select with the top node being "pin"
03:45 PM andypugh: I think that having pins and params of the same name is likely to confuse “setp” and so it shouldn’t be allowed.
03:47 PM pcw_mesa: I think the sserial driver removes these from the params created when the GDT is read but somehow fails on the 7I87
03:48 PM pcw_mesa: otherwise almost all cards would have this issue
03:48 PM andypugh: What are the pin and param names in question?
03:49 PM pcw_mesa: analog_in4 through analog_in7
03:49 PM andypugh: What is the meaning of “analog_in” as a parameter?
03:50 PM pcw_mesa: its useless
03:51 PM andypugh: Ah, but sort of happens by accident?
03:52 PM pcw_mesa: At some point (maybe for STMBL) all of the GDT got read and made into parameters and the GDT
03:53 PM pcw_mesa: may contain duplicates of process data
03:53 PM pcw_mesa: I am guessing that this is normally deleted by the driver
03:54 PM andypugh: Not explicitly
03:54 PM andypugh: But I can certainly look at making that happen
03:56 PM pcw_mesa: Let me take a look at some other card parameter data. I have never seen this issue before and can certainly trim the GDT so it only contains useful parameters
03:57 PM pcw_mesa: luckily this is an "out" pin so setp is not a problem and net works fine
03:58 PM pcw_mesa: why just 8 analog inputs show up as parameters is fairly mysterious
03:58 PM pcw_mesa: why just 4 of 8 I mean
03:58 PM andypugh: Oh, yes, that does seem odd.
03:59 PM pcw_mesa: thats why I thought the driver was removing parameters that duplicated pins
04:00 PM andypugh: Well, I am not saying that the driver doesn’t do that, just that I never made the driver do that.
04:01 PM pcw_mesa: and somehow tripped since there are multiple copies of the analog in pins in the GDT
04:02 PM pcw_mesa: some with differing numbers of pins (8 channels of 12 bit or 6 channel of 16 bit for example)
04:06 PM skunkworks: andypugh: =COS(PI()/$E$1)/COS((MOD(D3,(2*PI()/$E$1))-PI()/$E$1))
04:07 PM skunkworks: works in a spreadsheet. (creats a polygon of x sides)
04:07 PM andypugh: ?
04:07 PM skunkworks: I wanted to try cutting a hex with the mill..
04:07 PM andypugh: Ah, right.
04:08 PM skunkworks: and make something a bit more flexible.
04:08 PM andypugh: Why not use polar coordinates?
04:08 PM skunkworks: should be able to feed it the number of sides and such.
04:08 PM skunkworks: well - this would be spindle sync style motion.. If I could use polar I would.
04:09 PM skunkworks: but will probably be a offset of the axis
04:10 PM skunkworks: similar to what you did with the lathe - but 2 axis. (spindle has the cutter)
04:11 PM andypugh: Ah, OK.
04:11 PM skunkworks: The k&T would have a slow enough spindle to try it.
04:59 PM cerna: Anybody here tested how low-frequency the motion component loop can run?
05:12 PM skunkworks: https://www.geogebra.org/m/cXXGKUQk
05:51 PM andypugh: cerna: I think more folk have tested how _fast_ it can run
06:02 PM cradek: skunkworks: you don't need anything that complicated, since you only need the endpoints
06:03 PM skunkworks: cradek: I am converting the spindle rotation into offset movements to create a polygon with a single tooth cutter
06:03 PM cradek: ohhhh
06:04 PM cradek: never mind :-)
06:04 PM skunkworks: heh
06:04 PM skunkworks: So I feed it the spindle and it computes the offset for x and y - I think I have the math figured out.
06:04 PM andypugh: He might, I think he wants to do this: https://www.youtube.com/watch?v=T4q8gCpeY1A
06:05 PM skunkworks: right - except the tool is in the spindle and I am moving x and y.
06:05 PM andypugh: wsould it be rude to ask why?
06:05 PM andypugh: Are you trying to machine sharp corners?
06:06 PM andypugh: Like a positively-controled square-hole drill?
06:06 PM andypugh: I think I have seen that done.
06:07 PM skunkworks: yes - mainly want to see how well it works. (because)
06:08 PM andypugh: You realise its complicated? Because for any position of the cutting tooth there is an arc of possible positions for the spindle centre line.
06:10 PM skunkworks: yes - but currently I want to just try the cutter pointing from the center. (obviously not the best for all angles)
06:10 PM andypugh: Or, to put it another way, as the cutting tooth rotates, you have a wide choice of places that it could be touching the perimiter, and so a wide choice of X and Y
06:10 PM skunkworks: sue
06:10 PM skunkworks: sure
06:12 PM skunkworks: this would just point the cutter (which would be aligned so the cutting edge is exactly half way in the spindle. then the cutting edge would follow the polygon around always being 'tangent' to the shape. (if it was a circle(
06:12 PM andypugh: I thought for almost long enough to type a sentence that you can pick an tangent angle and constrain it to give only one spindle position, but you can’t as the spindle is constantly rotating whilst the faces are stright lines.
06:13 PM skunkworks: heh
06:14 PM andypugh: So you have to enter a face at one tangent angle then let that angle vary from the minimum acceptable to max acceptable through the length of the face, then when it gets to the corner it switches from max to min instantlay.
06:14 PM skunkworks: so really the only point that would be 'correct' tool angle would be at the center of the flat
06:14 PM andypugh: And, I think that’s the answer.
06:15 PM andypugh: You calculate the tangent angle to the current face of the current tool angle.
06:16 PM andypugh: Then how that corresponds to max or min is used to pick the corresponding point along the line.
06:16 PM skunkworks: but then I think you would need a machine with almost infanant acceleration/speed.
06:16 PM andypugh: And you need to solve the equation in X ad Y that puts the tool edge on the current side at that point along the line.
06:16 PM skunkworks: to be able to keep up.
06:17 PM andypugh: Yes, but also no.
06:17 PM andypugh: You calculate the ideal, and let LinuxCNC do its best.
06:17 PM skunkworks: I guess it would be quite a dance as it would be a loop of a path.
06:23 PM skunkworks: you would also have to take into account the tool diameter.
06:23 PM skunkworks: (so the non cutting parts of the tool don't hit.)
06:27 PM skunkworks: I feel like this could be done with actual spindle synce motion (a whole bunch of g33's strung together)
06:27 PM skunkworks: kinda like jmk's fuse..
06:27 PM skunkworks: fusee
06:30 PM skunkworks: really really short segments...
10:53 PM fjungclaus1 is now known as fjungclaus