Back
[00:57:48] <seb_kuzminsky> linuxcnc-build: force build --branch=master 0000.checkin
[00:57:49] <linuxcnc-build> build #4168 forced
[00:57:49] <linuxcnc-build> I'll give a shout when the build finishes
[01:54:22] <linuxcnc-build> Hey! build 0000.checkin #4168 is complete: Success [3build successful]
[01:54:22] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4168
[06:56:02] <jepler> 18:45:09 <seb_kuzminsky> i think that means hm2_eth tried to read a packet, but none was available
[06:56:05] <jepler> yes seb is right
[06:57:03] <jepler> the recv() call has timed out instead of receiving a UDP packet with 44 bytes
[06:59:09] <jepler> in 2.7.4, the timeout is very big, 200*1000*1000ns = 200ms, but if this is before 'loadrt hm2_eth' has finished then the code is not running in realtime mode yet so a possible but unlikely cause would be something causing a 200ms delay from sending the packet to trying to receive it
[06:59:35] <jepler> in the past I have started linuxcnc 10000s of times and not received this error once
[07:00:29] <jepler> I have a branch where I have been working on resilience against lost packets, but that is only when running realtime; I haven't done anything about packet loss during startup
[07:01:55] <jepler> I have found that you can 'tcpdump' packets on the hm2 ethernet port without compromising real-time performance, doing that will tell you if the packet is lost (as far as linux is concerned) or just came in too late
[09:20:00] <mozmck> thanks jepler. I'll be getting the pc and 7i92 so I can do some of that testing.
[12:45:32] <mozmck> I'm having a little trouble parsing the flow of the RUN command. The NML message has the type EMC_TASK_PLAN_RUN_TYPE, and that winds up getting issued as an immediate command as far as I can tell.
[12:46:32] <mozmck> But in emcTaskIssueCommand() for that type, it simply sets several variables.
[12:47:56] <mozmck> As far as I can tell the next thing is emcTaskExecute(), and I'm assuming the task.execState will be EMC_TASK_EXEC_DONE.
[13:08:08] <mozmck> But then I'm getting a bit lost.
[14:10:50] <PCW_> you lost a bit?
[14:13:58] <mozmck> yeah, or two
[16:03:25] <andypugh> Sometimes a job grows and grows.
[16:04:30] <andypugh> I am looking at adding spindle homing to the homing sequence. Which rather needs a struct to hold the spindle homing sequence, direction and offset. At which point there might as well be many spindles.
[16:04:52] <andypugh> (There does seem to be an occasional request for multi-spindle support).
[16:06:10] <andypugh> I think I can see where I need to interfere for the simple stuff. I propose adding an optional P-word to the M3 M4 an M5 commands.
[16:07:58] <andypugh> But then you get into the minutiae of spindle-synched motions, canned cycles, CSS etc.
[16:08:02] <cradek> tricky - I think the M commands don't currently claim/handle any other words
[16:08:15] <cradek> for instance I bet M3 G4 P1 is handled predictably
[16:08:27] <cradek> maybe M3 for all the spindles, M3.1, M3.2, M3.3 etc for individual ones?
[16:08:40] <cradek> err I wonder if there are decimalled Ms yet
[16:08:44] <andypugh> That was my original idea, but there are no decimal M-codes
[16:08:49] <cradek> TO THE BAT CAVE err CODE
[16:08:53] <cradek> ah, hmm
[16:09:09] <cradek> wonder which scheme is less terrible to add
[16:09:28] <andypugh> Good question.
[16:09:30] <cradek> wonder how other controls handle multiple spindles
[16:10:21] <andypugh> My initial question was whether it seems reasonable to simply ignore the clever stuff for the extra spindles, they just get a speed output in HAL and nothing more?
[16:11:00] <cradek> oh you mean like sync?
[16:11:19] <andypugh> Yes. And rigid tapping..
[16:12:32] <andypugh> I suspect that mutli-spindle rigid-tapping s just too hard a problem to consider, and nobody wants it anyway.
[16:12:40] <cradek> is multi-spindle useful without multiple motions/axes? (not that I want to grow your project more - I'm just wanting to understand the use case)
[16:12:59] <andypugh> I don’t really know.
[16:13:29] <andypugh> It just seemed odd to create a “spindles” struct with only one member, really.
[16:15:11] <andypugh> Incidentally, I looked at M31, M32 for extra spindles, and that’s OK clockwise but rather not-OK anticlockwise. :-)
[16:15:22] <cradek> haha ouch
[16:16:44] <cradek> I wonder how/if any other controls do multi-spindles
[16:16:48] <andypugh> Maybe I should ask on the users list? The problem then is that there becomes as expectation of introduction, and it is harder to just quietly give up on the project.
[16:17:51] <andypugh> Todd Zuercher first appeared on the forum with a gang-router question, though that probably doesn’t need individual speed control.
[16:18:18] <andypugh> I think quite a few people run live tooling on their lathes.
[16:18:43] <cradek> I recommend you don't in any way ask for a spec, but maybe ask for a use-case
[16:19:43] <andypugh> And the lathes that pick-up a workpiece in a second chuck to finish the machining are quite cool.
[16:22:34] <andypugh> Hmm.
https://www.youtube.com/watch?v=UQiOYbX5fJo does rigid-tapping with live-tooling.
[16:26:33] <mozmck> hmm, so a lathe with live tooling would be multi-spindle? I hadn't thought of that.
[16:27:04] <mozmck> Machine shop down the road has some lathes with a rear spindle to finish machining - it is very neat.
[16:36:18] <andypugh> cradek: Guess what M64 P1 G4 does?
[16:37:00] <cradek> heh I don't even know what M64 does
[16:37:16] <andypugh> Turns on a digital output
[16:37:35] <cradek> oh dear
[16:37:44] <cradek> I'd rather it would error than do whatever it does
[16:37:56] <andypugh> It turns on the output, and waits 1 second
[16:38:09] <cradek> that's ... elegant
[16:38:21] <mozmck> Isn't that what it should do?
[16:38:31] <andypugh> Yeah, that could be quite neat, if that is exactly what you wanted
[16:38:41] <cradek> it should error because since they both require P, you shouldn't be able to have them on one line
[16:39:08] <mozmck> huh, why not M64 P1 G4 P2 ?
[16:39:17] <cradek> because you can't have two P words on one line
[16:39:33] <cradek> remember the order of the things on the line means nothing in gcode
[16:39:38] <mozmck> I see, it used the P from before the G4
[16:40:05] <cradek> yeah there's not really a "before" - they both use the P value from that line
[16:40:16] <mozmck> I didn't know the order was irrelevant
[16:40:34] <cradek> yeah, for better or for worse, it is
[16:40:46] <andypugh> So, I started by wanting to home spindles, and now I am thinking that a necessary precursor is a check of G-codes that are not allowed to share a block…
[16:41:14] <cradek> traditionally the control reads in the words and puts them in the control's registers, and then runs the "block" (file line)
[16:41:26] <cradek> that's still pretty much the model
[16:42:56] <mozmck> I see.
[16:42:57] <cradek> http://www.linuxcnc.org/docs/html/gcode/overview.html#_item_order
[16:43:11] <cradek> except with comments and variables it's slightly trickier than that
[16:43:19] <cradek> we do actually document it, yay!
[16:43:21] <andypugh> Well, I guess I can introduce M4 P1 and not worry, I won’t make things any _more_ broken :-)
[16:44:07] <andypugh> I am likely to make an unqualified M5 stop all spindles.
[16:44:11] <cradek> andypugh: what a rabbit hole
[16:46:31] <cradek> I have used a control where multiple same words are allowed, and the order was important: for instance drill cycles could have several Z words, for the various heights in the operation
[16:46:56] <cradek> I think there were also some things like "cut a rectangle" which would take two XY corners or somesuch
[16:47:06] <mozmck> I *think* I'm gradually understanding the run and run-from-line. In order to make a simple rfl, it looks like I might need to have the interpreter skip to that line, instead of task skipping through the code as is done currently.
[16:47:15] <cradek> very limited memory, so they had a lot of cycles that saved you a few lines
[16:50:03] <cradek> mozmck: that seems plausible to me too
[16:50:07] <andypugh> For reference, I am currently basing this work on JA14
[16:52:46] <mozmck> Is there anything really preventing us merging JA into master now?
[16:53:53] <andypugh> In practical terms it means replacing Master with JA, I think. It’s not really a manageable merge I don’t think, not that I have tried.
[16:58:23] <jepler> fear of regressions. from a git standpoint, there appears to be a single merge conflict between master and ja14, and it's just irritating (it looks like one side reformatted code but I'm not sure yet from 30 seconds looking)
[17:01:10] <andypugh> OK, that’s good news. Dewey has been rebasing JA on master occasionally (hence the 14 versions).
[17:01:16] <mozmck> Isn't each new JA made by re-basing it on master?
[17:01:35] <mozmck> heh, answered before I hit enter!
[17:01:54] <mozmck> So it should not be too far off since ja14 is pretty recent
[17:03:18] <mozmck> There were concerns over some issues with JA a while back I remember, but it seems like dewey and others have fixed at least some of those issues.
[17:04:39] <jepler> yes, dewey has been very responsive fixing issues that seb has been reporting trying to use the gantry at his hackspace, and I think the results are getting better
[17:05:15] <jepler> I don't think there's a master list of known issues with ja, aside from what I am certain dgarr has in his head.
[17:10:12] <andypugh> I think that there are currently fewer problems with JA than with Master, as several things work better in JA than master, and I don’t know of anything that works worse. I run JA3 (I think) on my mill and the only thing I am not sure about is Y-axis rigid-tapping. That was “funny” when I tried it. But reading the docs, that might be expected.
[17:15:50] <jepler> yes, dgarr has chosen to fix certain bugs that came to his attention on JAx only and not on master, even though they affect both.
[17:16:20] <mozmck> :-) all the more reason to merge it to master soon!
[17:41:59] <andypugh> Bother! M19 already uses P.
[17:54:22] <andypugh> Does M3 E5 seem OK?
[17:58:03] <jthornton> E5?
[18:06:58] <andypugh> What would you prefer?
[18:29:49] <cradek> andypugh: do you think it might be important to turn on several spindles simultaneously?
[18:30:05] <cradek> again I really have no idea how they're used, but I think a lathe can sometimes hold a part from both ends
[18:30:28] <andypugh> How simultaeous would it have to be?
[18:30:32] <mozmck> Looks to me like the entire 400+ line contents of the function emcFormat() in emc.cc can be replaced with this: ((EMC_CMD_MSG*)buffer)->update(cms); return 1;
[18:30:34] <cradek> in that case, maybe you'd want to turn them both on together? M3.1 M4.2?
[18:31:01] <cradek> again I don't know
[18:31:18] <cradek> if that matters, I think you'd want to be able to put several on one line
[18:31:18] <andypugh> Yes, perhaps that is the way to do it.
[18:31:35] <cradek> if it doesn't matter, it doesn't matter
[18:32:09] <andypugh> Successive G-code lines are likely to be simultaneous _enough_ though, I suspect.
[18:32:50] <cradek> yeah it seems like if you're holding a part on both ends you need a much stronger guarantee than just turning the VFDs on at the same time
[18:32:57] <cradek> maybe it doesn't matter at all
[18:33:18] <cradek> pardon my thinking out loud
[18:33:28] <andypugh> In your M3.1 scheme, how does one set a spindle speed?
[18:33:57] <andypugh> One way is to associate the S-word with the most-recent M3 / M4
[18:34:30] <cradek> oh, good question
[18:34:44] <cradek> have you looked to see how any other control does it? (or do they?)
[18:35:46] <andypugh> I did a bit of google searching, but mainly found unanswered questions.
[18:37:31] <Tom_itx> they do do it but i can't say how
[18:37:40] <andypugh> Using E works out sort-of OK, because M3 S1000 E4 would work just the same as M3 E4 / S1000 M4
[18:37:56] <andypugh> I mean M3 E4 / S1000 E4
[18:39:34] <andypugh> The Wikipedia page on G-code says “S Defines speed, either spindle speed or surface speed depending on mode Data type = integer. In G97 mode (which is usually the default), an integer after S is interpreted as a number of rev/min (rpm). In G96 mode (CSS), an integer after S is interpreted as surface speed—sfm (G20) or m/min (G21). See also Speeds and feeds. On multifunction (turn-mill or mill-turn) machines,
[18:39:34] <andypugh> which spindle gets the input (main spindle or subspindles) is determined by other M codes.”
[18:39:48] <archivist> ask rob_h, he has a citizen sliding head, dunno if he has the one with second spindle plus live tooling on both
[18:40:28] <Tom_itx> looking at the okuma lathe book i have here, M12 M-tool spindle stop
[18:40:39] <Tom_itx> M13 M-tool spindle cw
[18:40:45] <Tom_itx> M14 ccw
[18:41:05] <andypugh> Yes, I just noticed that those M-codes are free
[18:41:29] <andypugh> The Wiki page says that M13 is spindle on + coolant on.
[18:41:39] <Tom_itx> i could scan these pages if it would be of any use
[18:41:44] <Tom_itx> just the g & m codes
[18:41:59] <rob_h> archivist, it has sub spindle yes well has 3 spindles as power tooling is classed the same address as main spindle
[18:42:15] <Tom_itx> there are 5 pages of M codes
[18:44:02] <rob_h> S1=3000 M04 (main spindle) S2=3000 M23 (sub Spindle)
[18:44:40] <Tom_itx> M23 is chamfer on (for thread cutting cycle) on the okuma
[18:44:45] <rob_h> M58 S3=3000 Power Tooling
[18:45:01] <andypugh> It looks like we could use M4/M4/M5, M13/M14/M15 M23/M24/M25 M33/M34/M35 for 4 spindles, but could only orient (M19) one of them.
[18:45:07] <Tom_itx> M58 chuck low air pressure
[18:45:09] <rob_h> yea well Mcodes can be what ever realy just what Citizen had free in the mitsubishi control i guess
[18:45:16] <Tom_itx> right
[18:46:34] <rob_h> i know M58 on our matsuura is coolant presure selection
[18:46:36] <andypugh> Unless there is a very well-established standard I think I prefer to use E-words. That works with M19, G76 etc.
[18:46:56] <andypugh> I don’t mean G76, do I?
[18:47:05] <rob_h> E to do?
[18:47:16] <Tom_itx> seems like M words are more common use
[18:47:28] <Tom_itx> even though they support a variety of functions
[18:47:41] <mozmck> According to SMID, M13/M14 or M103/M104 is used to control rotating tools (live tooling) in a lathe
[18:48:08] <Tom_itx> that's what the okuma uses here
[18:48:09] <rob_h> M14 and M13 on one lathe we had hardinge use to be Spindle and coolant on
[18:48:15] <andypugh> M100+ are defined as user m-codes in LinuxCNC though.
[18:48:36] <Tom_itx> http://www.editcnc.com/GandMcodes.html
[18:48:38] <Tom_itx> https://diy.haascnc.com/m-codes-lathes
[18:48:45] <Tom_itx> a couple just for reference
[18:49:22] <rob_h> as long as its a some what common sence sceem to follow
[18:50:18] <Tom_itx> http://okumacnc.blogspot.com/2011/03/list-of-m-codes-fanuc-control-m-codes.html
[18:50:25] <Tom_itx> fanuc supported
[18:50:41] <rob_h> well more so what the control builder does
[18:50:50] <rob_h> as any and all Mcodes and G codes can be changed
[18:51:01] <andypugh> Hmm, to allow multi-spindle threading (or, to put it a better way, to not exclude the possibility of multi-spindle threading) I think that the spindle-selector word would need to be D
[18:51:04] <rob_h> just a simple remap on the control to tell it what todo/use
[18:51:43] <rob_h> erm on citizen you have to do a Mcode sync which put spindles at same speed, does a phase match and then main is the master and sub has to follow very close
[18:52:05] <rob_h> if you want both spindles to sync , IE you pickup and want to use CSS or thread etc
[18:52:05] <mozmck> I could probably get some info from the shop nearby with a dual spindle lathe. I believe it's mori seiki
[18:52:53] <rob_h> but also the drives are digial linked. so control does not do much smart side just drives must sync each other and tell control its synced.. and drives take care of how much error there is if too much they alarm out
[18:53:07] <andypugh> I am trying to think of a scheme that isn’t limited to 2 spindles (in which scenario M13/14/15 is the easy way.
[18:53:33] <archivist> a multi spindle cnc wickman could be a target to think about too
[18:54:56] <rob_h> spindles can be power tooling also, so lathe with two spindles prob have two turets with live on each... and they are probly servo driven so can do tapping etc and are commaned same way any spindle is
[18:55:40] <andypugh> Well, if I decide on M3 D99 to start the 99th spindle we can have any number of spindles wthout running out of M-codes, at the expense of not being very standard. But it seems that there are few standards anyway,
[18:56:37] <andypugh> rob_h: Exactly, which is why you might want to at least leave the way clear for G33.1 D12 to rigid-tap with your 12th spindle...
[18:57:31] <rob_h> D is speed limit in CSS@?
[18:57:39] <rob_h> in G96
[18:57:46] <andypugh> Ah, yes, so it is.
[18:57:53] <andypugh> That’s a problem.
[18:58:33] <rob_h> but yes the concept seems valid/wise one to me if D or what ever is missing its assumed you mean main spindle (ie spindle 1)
[18:58:55] <andypugh> rob_h: Yes, it needs to be that way to not break existing code
[18:59:35] <andypugh> But if I can’t use D to say which spindles are CSS and I can’t use E to say which spindle we are threading with, it gets a bit intractable.
[19:00:34] <rob_h> yea becasue when have sub spindle now days, you are multipath control so its abit more easy to track spindle use
[19:01:52] <andypugh> I guess we would just need to be inconsistent, with E setting the spindle number in M3, M19, G96 and D being used (as the only spare letter) in G76
[19:02:32] <rob_h> plus when pickup with a sub. have to be running opasit direction to main rember as its other way around ;) so need M3 and M4 on same line if want to run both spindles at the same time
[19:03:45] <andypugh> Not possible.
[19:04:37] <andypugh> Synching spindles together would need to be a whole separate command.
[19:05:21] <mozmck> Can you use two letters? ie. SP?
[19:05:34] <andypugh> Something like M33 E1 D3 to synch spindle 1 to 3
[19:05:52] <rob_h> but dont need to be "synced" to do a pickup as such.. just running close to each spindle speed is good enouth to do a pickup.. only time to sync is if u want to phase Z match for threads or Caxis alinements. or zero mark the part (you gety zero or very little rub on unsynced)
[19:05:52] <mozmck> or even: M3 SPINDLE1
[19:06:22] <andypugh> mozmck: The only way to do that would be with “magic comments”
[19:06:43] <mozmck> ok
[19:06:50] <rob_h> something that seems easy at first is abit more tricky under the hood
[19:07:25] <andypugh> M3 SPINDLE1 would error when it tried to interpret PINDLE1 as a spindle speed
[19:07:40] <mozmck> bummer
[19:08:33] <Tom_itx> M3 HEAD1 M3 HEAD2
[19:09:03] <rob_h> can not do S1= S2= etc.. but if its just Sxxx then its the main(S1)
[19:09:07] <andypugh> “Unknown word beginnign with E”
[19:09:38] <andypugh> S1 is 1rpm.
[19:09:41] <cradek> CORRECT SOURCE AND RESUBNIT
[19:10:55] <cradek> (today I learned alt.lang.intercal still gets several posts every year)
[19:10:59] <andypugh> Every letter in G-code is a command. You can’t combine them in words. Well not wthout re-writing the entire interpreter, and if you were doing that you would use something better than Gcode.
[19:11:43] <mozmck> Is there something better than Gcode for this purpose in existence already?
[19:12:43] <Tom_itx> http://cnc.im/library/ftp/fanuc/a/A-79114E_01_050120.pdf
[19:12:50] <Tom_itx> dunno if that helps
[19:13:45] <rob_h> how to set the spindle selection paramiter i think that is
[19:15:49] <andypugh> mozmck: StepNC might be better than G-code
[19:16:14] <mozmck> hmm, seems like I've heard the name. I'll look it up.
[19:18:58] <andypugh> Tom_itx: That actually seems to hint that using the P-word to select spindles is an option.
[19:19:14] <Tom_itx> http://dl.mitsubishielectric.com/dl/fa/document/manual/cnc/ib1500269/ib1500269engf.pdf
[19:19:24] <Tom_itx> andypugh, i was also seeing that in the spindle section there
[19:19:30] <andypugh> Unfortunately M19 already uses P for something else.
[19:19:34] <Tom_itx> around P120ish
[19:20:35] <rob_h> Q prob not used alot
[19:20:58] <Tom_itx> could it be reused in context?
[19:21:59] <andypugh> Tom_itx: That uses the S1=1000 S2=750 syntax, but that isn’t something handles by the LinuxCNC parser
[19:23:05] <andypugh> rob_h: Q is not used much, but is used by G76 and M19
[19:23:20] <Tom_itx> http://cnc.im/library/ftp/fanuc/a/A-90046E_02_050722.pdf
[19:23:26] <Tom_itx> another version of fanuc's method
[19:25:45] <andypugh> Tom_itx: I don’t understank their documentation format
[19:26:18] <rob_h> its paramiters for spindle over ride i think
[19:26:27] <rob_h> how it effects multi spindles
[19:26:31] <andypugh> What does “SOV0 to SOV7<Gn030>” actually mean in terms of the G-code?
[19:27:56] <rob_h> its todo with Path or control if you like as its multi path control can run 2 or lots more programs indipenant but they can cross talk to each other in ways too , its always fun to program and proove out on mutli path controls :)
[19:28:31] <Tom_itx> yeah it looks to me that they can work together or separately
[19:28:47] <rob_h> it also sets which S1= which path/control, S2=wich path for multi path controls .. so if you do not write S1= or s2= in a program and just put Snnn then whcih ever path you write it in, commands that spindle
[19:28:50] <rob_h> kinda how it works
[19:29:53] <Tom_itx> isn't multipath ultimately what andy's after?
[19:30:23] <andypugh> No, that’s rather tooo hard
[19:30:26] <rob_h> no he wants a way to command a 2nd spindle.. or live tooling
[19:30:33] <Tom_itx> ok
[19:31:04] <Tom_itx> a first step toward that though
[19:31:05] <rob_h> multipathe into linuxcnc would be hard task to take on i think but a rewarding one as isee alot of multi turret & spindle lathes around now , just very old controls
[19:31:15] <andypugh> Well, actually, I started off just wanting to be able to home a spiondle for toolchanger use. But then fell down a number of rabbit holes.
[19:31:24] <Tom_itx> hah
[19:31:27] <rob_h> was one on Ebay in UK 5k bid dual spindle, dual turret
[19:32:45] <rob_h> was a Biglia make...
[19:34:14] <Tom_itx> the mitsu pdf spindle notes cover about 35 pages if it's anything that might help you... first glance it looks rather complete
[19:35:45] <andypugh> There seems to be many ways to do it, all of which need a major re-write of the LinuxCNC interpreter.
[19:36:15] <Tom_itx> if you want it to do more better things eventually that may be the case
[19:42:37] <andypugh> Time for me to sleep and forget where I was in this widely-spread hacking session :-)
[19:57:50] <skunkworks__> got to love it - linuxcnc expert
[19:57:55] <skunkworks__> http://www.cnczone.com/forums/uncategorised-cam-discussion/307546-cnc-software-3.html#post1888012
[20:08:59] <Tom_itx> must be, he's a gold member
[20:38:01] <PCW_> hmm... maybe I should not answer forum questions when I'm a "snappy pappy" as my SO says
[20:38:19] <jepler> schroot is neat. I should have used it before now. with it and qemu-user-static, I can create a chroot on my x86_64 machine that identifies as being armhf (but only about 1/10 as fast, for that genuine arm-style experience :-P)
[20:38:51] <skunkworks__> aww - I like snappy pappy!
[20:48:50] <jepler> This may take some time... done.
[20:48:54] <jepler> oh well it's finally done
[20:48:57] <jepler> This may take some time...
[20:49:01] <jepler> oh wait, now it needs to take some time again
[21:51:59] <jepler> real 7m28.173s
[21:52:09] <jepler> wow that's not bad at all for building linuxcnc in an emulated arm chroot
[21:52:45] <jepler> (real host is an 8-thread i7-4790K)
[21:53:33] <jepler> curious, some test failures
[21:53:44] <jepler> -argv[0]=userspace_count_names
[21:53:44] <jepler> +argv[0]=/home/jepler/src/linuxcnc/armhf/bin/userspace_count_names
[21:54:05] <jepler> *** /home/jepler/src/linuxcnc/armhf/tests/halui/jogging: FAIL: test run exited with 1
[21:56:13] <jepler> hm besides the first failure which has to do with the exact value of argv[0] it looks like every test which starts linuxcnc fails. I wonder why.
[21:56:19] <jepler> first printed error message is
[21:56:19] <jepler> libnml/buffer/shmem.cc 507: SHMEM: Can't take semaphore
[21:57:11] <jepler> hm but this one worked and it runs linuxcnc: Running test: /home/jepler/src/linuxcnc/armhf/tests/io-startup/nonrandom/no-tool-in-P0
[21:59:18] <mozmck> could it be timing issues?
[21:59:43] <jepler> not sure yet, I'm waiting for the full run of tests to finish before I dig into any individual failure
[22:00:23] <jepler> I think something else bad has happened, though. this time, rtapi_app and halcmd are both spinning at 99%CPU
[22:00:57] <jepler> and hmm how do you attach a debugger to a qemu-arm-static process usefully anyway
[22:02:07] <jepler> my first guess is going to be, qemu-user-arm doesn't actually implement atomic operations and so it's just not going to work out very well
[22:03:04] <mozmck> hmm. can the tests be run after install on an arm system?
[22:03:55] <jepler> I'm not entirely sure what my goal is
[22:09:27] <jepler> 'night
[22:10:01] <mozmck> goodnight. I may be too stuck in Interp to go to bed.
[22:10:23] <jepler> https://lists.nongnu.org/archive/html/qemu-devel/2010-08/msg00884.html
[22:10:29] <jepler> > Currently, qemu implements this instruction as a load
[22:10:29] <jepler> followed by a store, in a way vulnerable to race conditions.