#linuxcnc-devel Logs

Dec 05 2018

04:28 AM Jin^eLD: morning
04:32 AM Jin^eLD: guys, we were further fiddling with the MAHO mill setup and my gearbox comp yesterday and ran into a problem where we are not sure if its our misunderstanding of how things shouild be or if its something that missing or is just "like that" in LinuxCNC
04:32 AM Jin^eLD: main question for us would be how to deal with it or work around that
04:32 AM Jin^eLD: its about stopping the spindle
04:33 AM Jin^eLD: say we have G code that starts the spindle at 300 rpm, waits 10 secs, changes to 500 rpm, simple use case
04:34 AM Jin^eLD: so whats currently happening for us is: the gearbox comp gets the request for 300 rpm, sets up the gear, spindle starts at 300, and after 10 secs we received a speed change request, the gearbox comp sees that the spindle is running and needs to stop it (thats how this machine works), so I ask top stop the spindle
04:35 AM Jin^eLD: and I think the way we do it is not correct but we did not find another one, currently my stop request pin is netted to halui.spindle.stop
04:35 AM Jin^eLD: spindle stops, so I am about to change gear to match 500 rpm
04:35 AM Jin^eLD: but I receive a request to set speed 0 from LinuxCNC
04:35 AM Jin^eLD: which probably a reaction to stopping the spindle
04:36 AM Jin^eLD: as as a result I then switch into neutral and the 500 rpm are never set because the command was overriden by linuxcnc setting 0 rpm
04:36 AM Jin^eLD: any ideas how to deal with that? basically we'd need the "speed in rpm" to be decoupled from "spindle is on/off"
04:39 AM Jin^eLD: in the motion man page I only saw spindle speed settings, but no on/off
04:41 AM KimK: Some spindles need a "jog" or "creep" function to change gears, which sometimes can be from the spindle motor and sometimes has to be a separate small motor which rocks the gears back-and-forth at a slow speed.
04:42 AM Jin^eLD: we need "twitching" but the machine has extra pins for it, it turns the spindle cw/ccw in some millisecond reange delay steps, but linuxcnc does not know that/does not have to know, so that part is not an issue, we just need to make sure "spindle is stopped" while we switch gears
04:43 AM Jin^eLD: but how to do that without receiving a spindle speed override?
04:43 AM KimK: If your spindle drive is complex enough (external mode change, selectable parameters, etc.) , some they have a jog mode which is optimized for very low speeds. (Ah, OK, I just looked up, you have something like this.)
04:45 AM Jin^eLD: one thing I thought of would be simply not telling LinuxCNC that I am stopping the spindle for a gearchange and then to restore the state (i.e. restart it if it was running before the change)
04:45 AM Jin^eLD: but I am not sure about potential implications if we "secretly" stop the spindle without telling the rest of the system about it
04:46 AM KimK: Yes, gear change is usually in HAL (is that external to LinuxCNC, heh?), either via a component or classicladder. (Or something else? External device, maybe?)
04:46 AM Jin^eLD: I wrote a C component for changing gears
04:47 AM Jin^eLD: and we netted it into HAL
04:47 AM KimK: Gear change is considered spindle live, "Machine may start at any time" and all that.
04:48 AM Jin^eLD: well we have the feeling that the design is very much VFD oriented, but we have a mechanical gearbox and no clutch :) so we need to stop when we change speed (gears)
04:48 AM Jin^eLD: i.e. linuxcnc design seems to be more vfd oriented
04:49 AM KimK: Do you have "crashbox" gears or clutches of some kind?
04:49 AM KimK: I'm guessing crashbox?
04:49 AM Jin^eLD: not familiar with the term, whats a crashbox?
04:50 AM Jin^eLD: its an unsynchronized gearbox without a clutch, so you need to stop the spindle, move the gears around, retsart
04:50 AM Jin^eLD: *restart
04:50 AM KimK: Unsynchronized gears that slide back-and-forth on a shaft and contact the teeth of other gears on other shafts (which may also slide back-and-forth).
04:51 AM Jin^eLD: oh yeah, that sounds exactly like what we have :)
04:52 AM KimK: OK, then you must jog or you will be "stuck" a certain statistical percentage of the time (depending how the teeth happen to line up).
04:52 AM Jin^eLD: ehm... how is that related to my question about the motion API? :) you lost me here
04:53 AM Jin^eLD: the comp itself works fine, we have an issue with integration into LinuxCNCs logic so it all plays smoothly together
04:53 AM KimK: You might also want to get up to jog speed before attemping the shift, in case spindle jog mode torque is low.
04:54 AM Jin^eLD: no we don't want that :) there is only one motor speed, rest is done by gears; intead of "jogging" this machine requires so called "spindle twitching" and the comp as such works just fine, gear change is implemented and working, my issue is with integration into LinuxCNC
04:56 AM KimK: Sorry, I misunderstood, what is not working?
04:58 AM Jin^eLD: well, what I wrote from "morning" till your first comment... when we stop the spindle to do our shifting, LinuxCNC reacts to us stopping the spindle by setting motion.spindle-speed-out to zero, which effectively overrides the speed that we oringally were going to set
05:05 AM KimK: If you stopped the spindle via LinuxCNC then wouldn't that be correct? I'm re-reading what you wrote earlier with this new insight.
05:06 AM KimK: It seems to me that your gear change component has to sometimes work with (pass-thru?) LinuxCNC, and sometimes take over from LinuxCNC in special situations that LinuxCNC doesn't know about, like your special gear change.
05:06 AM Jin^eLD: well that is my question... if it would be ok/safe to "hide" some information from LinuxCNC, but that did sound like a workaround to me
05:07 AM Jin^eLD: or if there is some poin or something that we missed where we could say "desired speed is XX" but the spindle is on/off right now
05:07 AM Jin^eLD: the motion.spindle-speed-out pin sets the desired speed, its not the current status
05:08 AM Jin^eLD: but in LinuxCNC "spindle off" seems to logically mean "desired speed 0"
05:09 AM Jin^eLD: thats what I am trying to figure out - if my assumption is correct, if we are missing something in the API for machines like that, or if I should just try to work around it by hiding some information from LinuxCNC in certain situations (this I wanted to avoid, i.e. if it thinks the spindle is running - what would prevent it from activating a feed and trying to cut?)
05:10 AM Jin^eLD: on the other hand, if you guys tell me that its guaranteed that it won't continue with G code execution until I report back the speed that was requested, then this "hidden stop-shift-restart spindle" thing would probably be OK
05:10 AM Jin^eLD: but I want to confirm that first :)
05:11 AM KimK: No, hiding information (or taking over) is pretty common, considering the many different designs of machines. You can also "work with" (workaround?) LinuxCNC if you wish, it's flexible. Take over? Lie to it?
05:12 AM Jin^eLD: well, I just want to make sure that the work around has no side effects which I may not be aware of and if I can make assumptions about execution as I described above, because that would actually be quite important
05:14 AM KimK: This is one reason I'm not a big fan of "auto-on-the-fly" gear changes, I prefer to let the operator pick what gear he wants to run in and then set it with an M-code, rather than auto-gear change as in your 300-0-500 example. But that mode is popular and a lot of people use it, and LinuxCNC can do it, so there you go.
05:15 AM KimK: s/300-0-500/300-(jog/creep/twitch)-500/
05:16 AM KimK: If you're using auto-change, you'll probably want to disallow inadvertent gear changes caused by using the spindle override.
05:17 AM Jin^eLD: I only wrote the gearbox comp so not that familiar with g-code, I think my friend (who owns the MAHO) was using "S" commands to set the speed
05:17 AM Jin^eLD: not sure if that is considered "auto on the fly?"
05:19 AM KimK: Your spindle motor, was it originally (factory) on-off, or off-lo-high, or some such? Your VFD is a recent addition?
05:19 AM Jin^eLD: no we do not have a VFD
05:20 AM Jin^eLD: factory setup is on/off and a gearbox, thats also how we do it
05:20 AM Jin^eLD: I was saying that LinuxCNC logic has VFDs in mind, at least that is my feeling, LinuxCNC thinks that spindle off == desired speed 0
05:21 AM Jin^eLD: which would be true in a VFD case I guess, but if you have a gearbox than spindle on/off and the "desired speed" are separate things, as desired speed is the actually desired gear setting and spindle can be on or off independent of that
05:21 AM KimK: Generally S sets the spindle drive speed, but it possible to use S as gear changes, particularly if the motor is (was) restricted to a narrow RPM range.
05:22 AM KimK: How do they obtain the twitching?
05:23 AM Jin^eLD: the MAHO has pins desginated for it, I am not sure if they use the main motor or othe rmeans but they are able to shake the spindle somehow, I need to activate each pin in alternation cw-ccw-cw-ccw with some delays
05:25 AM Jin^eLD: so before doing the actual gear shift I stop the spindle, start twitching, do the gearshift magic, stop twitching, then restart the spindle if it was running earlier or leave it be if it was not running before
05:26 AM KimK: Are you setting up to do speed ranges based on the S-code?
05:26 AM Jin^eLD: I quantize the requested speed to the nearest of what the machine is capable of
05:26 AM KimK: OK, that
05:26 AM KimK: oops
05:27 AM Jin^eLD: our problem is only the fact that the second S command gets overwritten by LinuxCNC as soon as LinuxCNC sees that the spindle was stopped
05:28 AM Jin^eLD: i.e. if the spindle is already on, and I receive S500 (motion.spindle-speed-out 500), I stop the spindle to do that shift, but as soon as I do that LinuxCNC sends me motion.spindle-speed.out 0
05:28 AM Jin^eLD: which overrides the original request (500 in the above example)
05:28 AM Jin^eLD: so instead of switching to 500 I go to neutral because thats what I was told to do
05:30 AM Jin^eLD: i.e. told to do by LinuxCNC, not by our g-code program
05:30 AM KimK: That's OK, if your component remembers that it is in a gear change. It might even work for you, if you need to stop the spindle anyway.
05:31 AM Jin^eLD: well my component does not know who sends it data, it just receives speed change requests by monitoring motion.spindle-speed-out
05:31 AM KimK: Old speed replaced by new (desired) speed, but gears wrong.
05:31 AM Jin^eLD: so I get 500, I want to go to 500, but as soon as I stop the spindle in order to go to 500 I received 0
05:32 AM Jin^eLD: and I dont know if I received zero because that was part of the code, operator command or in this case - because LinuxCNC interpreted "spindle stopped" as "ok, lets set desired speed pin to zero"
05:32 AM Jin^eLD: the comp simply executes all desired speed requests it receives...
05:32 AM Jin^eLD: but that 0 is "wrong"
05:32 AM Jin^eLD: or unexpexted
05:33 AM Jin^eLD: *unexpected
05:33 AM Jin^eLD: its LinuxCNC interpreatation of "spindle stopped"
05:43 AM KimK: Maybe you should be looking at: "motion.spindle-speed-out-rps - (float, out) Commanded spindle speed in rotations per second. Positive for spindle forward (M3), negative for spindle reverse (M4). " ? (Taken from http://www.linuxcnc.org/docs/2.7/html/config/core-components.html )
05:44 AM KimK: Does that one cut off too?
05:45 AM KimK: If you want to avoid negative numbers, there's also: motion.spindle-speed-out-abs - (float, out) Commanded spindle speed in rotations per minute. This will always be a positive number.
05:55 AM KimK: Maybe this will be useful even though there's only two speeds: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MazakSpindleGearChange (I would have exchanged steps 7 & 8, and exchanged steps 13 & 14, but that's just me.)
05:55 AM Jin^eLD: well, I did not monitor these pins explicitly, but I would assume that if LinuxCNC sets desired speed 0 on spindle-speed-out it will most likely sync all the related pins as well
05:57 AM Jin^eLD: on the forums we got the following: "The default behavior of motion.spindle.speed.out.abs is to go to 0 rpm when motion.spindle-on goes false (0)."
05:57 AM Jin^eLD: and this is exactly the problem we have :)
05:59 AM Jin^eLD: but I think the approach of "hiding" the fact of stopping the spindle during the shift would work, as linuxcnc waits for spindle-at-speed to continue with the code
06:01 AM rmu: Jin^eLD: did you look at remapping the S command
06:02 AM Jin^eLD: please elaborate :)
06:02 AM Jin^eLD: how would that work and what would it allow us to do differently?
06:03 AM rmu: http://linuxcnc.org/docs/html/remap/remap.html#_remapping_other_existing_codes_s_m0_m1_m60
06:03 AM rmu: you have complete control what S does
06:03 AM Jin^eLD: first paragaph sounds interesting, thank you
06:04 AM rmu: so program executes "S500", your remapped codes figures out if it needs to change gear, stops spindle, changes gear, start spindle, and continues program
06:05 AM Jin^eLD: hmm, that sounds like a possible way
06:05 AM Jin^eLD: I'd actually prefer to keep all logic in the comp, but if thats not entirely possible - remapping sounds like something we might get away with, thank you
06:09 AM rmu: i think you can use iocontrol iopins like in toolchange to communication to HAL
06:09 AM Jin^eLD: oh, you mean pretend we are switching tools which would kind of "stop the spindle"?
06:10 AM Jin^eLD: I was thinking about remapping, buti f we remap S300 S500 to S300 S0 S500 then we have one neutral shift (0) which is not needed, so really stopping the spindle without changing the speed is what we want
06:10 AM Jin^eLD: would those iocontrol things allow to do that?
06:11 AM rmu: no i mean you connect you component not to motion.spindle-speed but to motion.analog-out-whatever
06:11 AM Jin^eLD: oh
06:11 AM rmu: and that value you can control from your remapped python code
06:11 AM Jin^eLD: our comp is C, but I assume that could also be controlled in C
06:11 AM rmu: and connect that value to your C comp
06:11 AM rmu: via HAL
06:12 AM Jin^eLD: oh ok, so some kind of a python proxy
06:13 AM rmu: yes, a kind of python shim that generates the info your toolchanger component needs
06:13 AM rmu: s/toolchanger/gearchanger/
06:13 AM Jin^eLD: sounds like a bit of overhead but could work as well
06:13 AM Jin^eLD: ok so we have identified 3 options for now
06:14 AM Jin^eLD: 1. do it silently in the comp, dont tell linuxcnc, 2. remap g-code 3. use motion.analog-out* with python proxy
06:14 AM rmu: 3 implies 2
06:15 AM Jin^eLD: right...
06:16 AM Jin^eLD: I'll give it a thought, thank you, and more input is alwayx welcome, I'll look at the backlog in the evening, gotta run now
06:16 AM Jin^eLD: bbl :)
06:16 AM Jin^eLD is now known as Jin|away
06:19 AM rmu: ttyl
09:39 AM skunkworks: jepler: wasn't it you that played around with re-writing halscope in something else? I remember a screen shot of a cool looking scope.
09:48 AM cradek: maybe we should be using Xview or Athena so it'll actually work for the next 10 years without churn screwing it up
10:07 AM Roguish: CMorley: good morning. how can I checkout (see) what you're working on?
10:07 AM Roguish: a git pull or something?
10:08 AM CMorley: qt5vcp_py2 is the current working branch. - you would need to checkout that branch.
10:50 AM rmu: re. halscope: wouldn't it be possible to reuse something like sigrok?
10:50 AM rmu: sigrok pulseview
11:07 AM skunkworks: well - it has to look and work exactly the same as halscope.. otherwise I won't like it.
11:07 AM skunkworks: ;)
11:11 AM hazzy-m: sigrok looks nice
11:14 AM rmu: there is a lot that could be improved in halscope ;)
11:17 AM skunkworks: Oh - certianly - I am kidding
11:25 AM hazzy-m: rmu: skunkworks might rely on some of HALScope's idiosyncrasies ...
11:25 AM hazzy-m: https://xkcd.com/1172/
11:31 AM Roguish: it would be nice if an FFT were added to halscope and tuning in general. servo tuning in the frequency domain is really good.
11:56 AM skunkworks: heh - no. Halscope works as expected
12:47 PM rmu: it should not be that hard to connect the halscope realtime component to sigrok
01:13 PM jepler: skunkworks: I dabbled once or twice with replacing halscope, but I was too ambitious and never got anywhere
01:14 PM jepler: actually, making a plugin for sigrok or something might make more sense these days, I think the open source "scope UI" may be mature enough to allow it to make sense.
01:14 PM jepler: oh hey rmu just said that
01:14 PM * jepler hides again
05:30 PM jepler: hum I guess the one I recently did some fixes on was demux
05:30 PM jepler: and in master only
05:30 PM jepler: and "recently" = a month or more ago
05:41 PM andypugh: Dewy found an obsure bug (segfault) with even but not power-of-two sized muxes. And then when fixing that I found that the FU node had never worked
05:42 PM andypugh: (Dewey, I mean) Sorry Dewey
05:44 PM rene_dev_: andypugh huge merge conflict incoming...
05:45 PM andypugh: Reverse run?
05:48 PM rene_dev_: andypugh no, but thats also on the todo list...
05:48 PM rene_dev_: https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-overhaul-2.7-with-UI-warning
05:48 PM rene_dev_: still to be tested, but fixes at least 2 bugs
05:49 PM andypugh: Ah, but big multispindle merge problems?
05:49 PM andypugh: Going in 2.7?
05:49 PM rene_dev_: no, as its based on 2.7
05:50 PM rene_dev_: yes
05:50 PM andypugh: Then I guess I can manually merge it
05:50 PM andypugh: (to master)
05:50 PM rene_dev_: problems will come when it goes into master... but still needs testing
05:50 PM rene_dev_: https://github.com/LinuxCNC/linuxcnc/issues/167
05:50 PM rene_dev_: https://github.com/LinuxCNC/linuxcnc/issues/164
05:50 PM rene_dev_: should fix those bugs