#linuxcnc-devel Logs

Oct 15 2018

01:53 PM hazzy-m: I am a big fan of the branch-commit-pr-merge workflow
01:55 PM hazzy-m: Having changes enter master thru a PR makes it easy to document what changes were made, by whom, and why, and provides a convenient way to discuss changes before (and after) they have been merged.
01:55 PM hazzy-m: But when it takes weeks for even the simplest of PRs to be merged it becomes difficult to move forward
01:55 PM hazzy-m: I have to keep track of what has and has not been merged so things don't get fixed twice
01:55 PM hazzy-m: and if something is fixed twice by accident (which I did this morning), then it will probably end up making the life of whoever ends up merging it harder due to conflicts
01:55 PM hazzy-m: I know you all are busy, and several of you aren't spending nearly as much time on LinuxCNC these days, which I completely understand, so don't think I am complaining, I am not!
01:56 PM hazzy-m: it's just that there is less man power here than there used to be to take care of things like PRs.
01:57 PM hazzy-m: So I guess what I am getting at is, while I would rather not have the responsibility of push access to the main repo, if it would reduce the load on you all for all these trivial doc fix PRs I keep making then maybe that is something we could consider.
03:18 PM jthornton: hazzy-m: if you see doc fixes that I miss and I miss a lot let me know and I'll take care of them
03:19 PM andypugh: I am baffled.. (again)
03:19 PM andypugh: As far as I can see the spindle speed for each spindle should be stored in emcstatus.
03:20 PM hazzy-m: jthornton: Thank you! But sometimes it is easyer to fix them than explain what needs to be fixed!
03:21 PM andypugh: This line here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/task/emccanon.cc#L1839
03:23 PM andypugh: But if I add some printf : for (int i = 0; i < 3; i++) {printf("spindle %i speed %f\n", i, emcStatus->motion.spindle[i].speed) ;}
03:23 PM andypugh: It seems that all the spindle speeds get set to zero between calls, but I haven’t managed to find anywhere else in the code that puts values in that array..
03:26 PM andypugh: Ah, a clue, only in MDI…
03:27 PM andypugh: G-code behaves as-expected
03:32 PM JT-Shop: hazzy-m: I get in trouble with my wife all the time not saying what I'm thinking ie taking short cuts lol... if you have a PR for docs and I miss it let me know
03:33 PM * JT-Shop heads to the fab shop to make some sparks
04:01 PM hazzy-m: andypugh: Thank you! Now my multispindle test UI should run again
04:04 PM andypugh: hazzy-m: Do you have the time to look at this spindle speed thing? Maybe a fresh set of eyes can help?
04:06 PM hazzy-m: andypugh: sure, I'll try!
04:06 PM andypugh: There used to be a static global variable in emccanon that held the current spindle speed. I moved that to inside the emcStatus structure (of type EMC_STAT defined in emc_nml.hh)
04:07 PM hazzy-m: just testing your changes to the spindle overrides, still not right, but much more predictable, which is a step in the right direction!
04:07 PM andypugh: But it looks like that is reset to zero every time emccanon exits (though I am about to look to see if anything in the joint stuff is retained)
04:09 PM hazzy-m: ok, i'm going to try and understand how emccanon SET_SPINDLE_SPEED works
04:30 PM andypugh: You don’t particularly need to. The real question is why the emcStatus->motion.spindle[i].speed gets set to zero all the time
04:31 PM andypugh: Before: spindle 0 speed 0.000000
04:31 PM andypugh: Before: spindle 1 speed 0.000000
04:31 PM andypugh: Before: spindle 2 speed 0.000000
04:31 PM andypugh: After: spindle 0 speed 100.000000
04:31 PM andypugh: After: spindle 1 speed 0.000000
04:31 PM andypugh: After: spindle 2 speed 0.000000
04:31 PM andypugh: Happens every time with S100.
04:31 PM andypugh: I assume that something in the declarations of EMC_STAT type isn’t right, and the structure isn’t static.
04:33 PM hazzy-m: I don't know C/C++, so I'm trying to get the gist of how it all works
04:33 PM hazzy-m: is it possible to print the object ID like it is in python and see if it changes?
04:34 PM hazzy-m: then at least you'd know if it was static or not
04:35 PM andypugh: The address doesn’t change....
04:36 PM andypugh: printf("Address of spindle speed = %p\n", &emcStatus->motion.spindle);
04:36 PM hazzy-m: but I guess it could be a new instance at the same adress ...
04:36 PM andypugh: Gives the same answer every time
04:36 PM andypugh: Yes, possibly. I know very little about C++ too
04:37 PM andypugh: I normally only work in C.
04:57 PM hazzy-m: andypugh: amiright that there there are no other emcStatus values set in emcconnon?
04:58 PM andypugh: There is one other thing set.
04:59 PM andypugh: emcStatus->task.programUnits = in_unit;
05:00 PM andypugh: Before I changed things about everything was stored as globals in emccanon, I will go back to that, perhaps there is a reason that I don’t know.
05:08 PM hazzy-m: I'm wondering if it is something simple in the syntax. In `emcStatus->task.programUnits = in_unit` programUnits is a int (I assume) whereas in `emcStatus->motion.spindle[s].speed` spindle is an array, so wonder if you might need to dereferance it or something
05:22 PM hazzy-m: andypugh: I got a negative speed to show up in emcStatus before setting the speed
05:23 PM * hazzy-m sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/GprHtLkgdBpcSnQoVoDwJGIh >
05:23 PM hazzy-m: which would indicate it is not being reset to 0 ...
05:24 PM andypugh: It works if you put the m3 on the same line, and that seems to indicate that if you stay “in” emcannon it is OK.
05:25 PM hazzy-m: yes, but I got a neg with out using any m codes, so something is persistant
05:25 PM andypugh: (It also works in G-code, so it looks like emcStatus goes out of scope when you complete an MDI command)
05:25 PM hazzy-m: could be
05:25 PM hazzy-m: investigation to be continued after a supper break ..
06:34 PM Jin^eLD is now known as Jin|away
07:34 PM hazzy-m: andypugh: the emcStatus values are updated somewhere, but I can't find were. Do you know where that occurs?
07:34 PM andypugh: I think I have a fix ready to push
07:34 PM hazzy-m: excellent!!
07:34 PM andypugh: My suspicion is the call to GET_EXTERNAL_SPEED
07:35 PM andypugh: But I went with putting everything back in emccanon module-global variables.
07:43 PM hazzy-m: better
07:44 PM hazzy-m: M3 and M4 change the direction of BOTH spindle ..
07:45 PM hazzy-m: if issued without an $ word
07:47 PM andypugh: Yes, that’s deliberate
07:48 PM hazzy-m: seems like it should give an error, no?
07:48 PM andypugh: M3 M4 M5 operate on all spindles simultaneously unless told otherwise
07:48 PM andypugh: This was part of the plan to make simultaneous starts easy.
07:50 PM andypugh: Before I realised that the signals won’t go to the hardware until the write function, so they would start simultaneously anyway
07:50 PM andypugh: Anyway, nearly 2am here, time to sleep.
07:51 PM hazzy-m: hmm, but it seems a little dangerous to have both start, it would be awful easy to start both from MDI by accident and cause an accident. I think for it should requite the $ word for a multispindle machine
07:51 PM hazzy-m: night
08:02 PM skunkworks: pcw_mesa: that worked!
08:03 PM Tom_L: yay
08:04 PM skunkworks: https://www.youtube.com/watch?v=mpB8O9_5_Ro
08:04 PM skunkworks: it needs a simple amplifier on the pin.. I just cobbled it together for testing
08:05 PM skunkworks: the encoder scale ended up being .065 I have not figured out what that means yet
08:05 PM skunkworks: it must actually use one or all of the hal sensors - because it fires when I turn the spindle by hand
08:06 PM skunkworks: pcw_home:
08:08 PM skunkworks: there are pid settings in the drive - but I have yet to find a manual for it that I can read
08:08 PM skunkworks: (it hunts around the setpoint for a bit)