#linuxcnc-devel | Logs for 2018-12-05
Back
[00:07:01] -!- KimK has quit [Remote host closed the connection]
[00:16:56] -!- KimK has joined #linuxcnc-devel
[00:57:39] -!- ve7it has quit [Remote host closed the connection]
[03:42:47] -!- selroc has joined #linuxcnc-devel
[05:27:01] -!- Jin^eLD has joined #linuxcnc-devel
[05:27:04] <Jin^eLD> morning
[05:30:20] <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
[05:30:34] <Jin^eLD> main question for us would be how to deal with it or work around that
[05:30:45] <Jin^eLD> its about stopping the spindle
[05:31:23] <Jin^eLD> say we have G code that starts the spindle at 300 rpm, waits 10 secs, changes to 500 rpm, simple use case
[05:33:07] <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
[05:33:27] <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
[05:33:40] <Jin^eLD> spindle stops, so I am about to change gear to match 500 rpm
[05:33:55] <Jin^eLD> but I receive a request to set speed 0 from LinuxCNC
[05:34:02] <Jin^eLD> which probably a reaction to stopping the spindle
[05:34:26] <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
[05:35:10] <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"
[05:37:15] <Jin^eLD> in the motion man page I only saw spindle speed settings, but no on/off
[05:39:24] <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.
[05:40:55] <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
[05:41:27] <Jin^eLD> but how to do that without receiving a spindle speed override?
[05:42:11] <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.)
[05:43:32] <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)
[05:44:05] <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
[05:44:53] <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?)
[05:45:11] <Jin^eLD> I wrote a C component for changing gears
[05:45:25] <Jin^eLD> and we netted it into HAL
[05:45:47] <KimK> Gear change is considered spindle live, "Machine may start at any time" and all that.
[05:46:38] <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)
[05:46:53] <Jin^eLD> i.e. linuxcnc design seems to be more vfd oriented
[05:47:27] <KimK> Do you have "crashbox" gears or clutches of some kind?
[05:47:39] <KimK> I'm guessing crashbox?
[05:48:02] <Jin^eLD> not familiar with the term, whats a crashbox?
[05:48:31] <Jin^eLD> its an unsynchronized gearbox without a clutch, so you need to stop the spindle, move the gears around, retsart
[05:48:44] <Jin^eLD> *restart
[05:48:58] <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).
[05:49:21] <Jin^eLD> oh yeah, that sounds exactly like what we have :)
[05:50:17] <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).
[05:50:51] <Jin^eLD> ehm... how is that related to my question about the motion API? :) you lost me here
[05:51:50] <Jin^eLD> the comp itself works fine, we have an issue with integration into LinuxCNCs logic so it all plays smoothly together
[05:51:55] <KimK> You might also want to get up to jog speed before attemping the shift, in case spindle jog mode torque is low.
[05:53:03] <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
[05:54:18] <KimK> Sorry, I misunderstood, what is not working?
[05:56:26] <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
[06:03:50] <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.
[06:04:15] <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.
[06:04:55] <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
[06:05:31] <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
[06:05:50] <Jin^eLD> the motion.spindle-speed-out pin sets the desired speed, its not the current status
[06:06:25] <Jin^eLD> but in LinuxCNC "spindle off" seems to logically mean "desired speed 0"
[06:07:25] <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?)
[06:08:22] <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
[06:08:30] <Jin^eLD> but I want to confirm that first :)
[06:09:20] <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?
[06:10:33] <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
[06:12:29] <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.
[06:13:48] <KimK> s/300-0-500/300-(jog/creep/twitch)-500/
[06:15:13] <KimK> If you're using auto-change, you'll probably want to disallow inadvertent gear changes caused by using the spindle override.
[06:15:59] <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
[06:16:09] <Jin^eLD> not sure if that is considered "auto on the fly?"
[06:18:34] <KimK> Your spindle motor, was it originally (factory) on-off, or off-lo-high, or some such? Your VFD is a recent addition?
[06:18:34] <Jin^eLD> no we do not have a VFD
[06:18:34] <Jin^eLD> factory setup is on/off and a gearbox, thats also how we do it
[06:18:56] <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
[06:19:39] <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
[06:20:02] <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.
[06:20:53] <KimK> How do they obtain the twitching?
[06:21:42] <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
[06:23:33] <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
[06:24:28] <KimK> Are you setting up to do speed ranges based on the S-code?
[06:24:49] <Jin^eLD> I quantize the requested speed to the nearest of what the machine is capable of
[06:24:59] <KimK> OK, that
[06:25:02] <KimK> oops
[06:25:42] <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
[06:26:31] <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
[06:26:45] <Jin^eLD> which overrides the original request (500 in the above example)
[06:27:08] <Jin^eLD> so instead of switching to 500 I go to neutral because thats what I was told to do
[06:28:25] <Jin^eLD> i.e. told to do by LinuxCNC, not by our g-code program
[06:28:28] <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.
[06:29:44] <Jin^eLD> well my component does not know who sends it data, it just receives speed change requests by monitoring motion.spindle-speed-out
[06:29:49] <KimK> Old speed replaced by new (desired) speed, but gears wrong.
[06:30:13] <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
[06:30:39] <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"
[06:30:53] <Jin^eLD> the comp simply executes all desired speed requests it receives...
[06:31:03] <Jin^eLD> but that 0 is "wrong"
[06:31:11] <Jin^eLD> or unexpexted
[06:31:16] <Jin^eLD> *unexpected
[06:31:25] <Jin^eLD> its LinuxCNC interpreatation of "spindle stopped"
[06:41:33] <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 )
[06:42:19] <KimK> Does that one cut off too?
[06:43:12] -!- selroc has quit [Quit: Leaving]
[06:44:13] <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.
[06:53:20] <KimK> Maybe this will be useful even though there's only two speeds: http://wiki.linuxcnc.org (I would have exchanged steps 7 & 8, and exchanged steps 13 & 14, but that's just me.)
[06:54:05] <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
[06:55:30] <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)."
[06:55:35] <Jin^eLD> and this is exactly the problem we have :)
[06:57:34] <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:59:59] <rmu> Jin^eLD: did you look at remapping the S command
[07:00:26] <Jin^eLD> please elaborate :)
[07:01:07] <Jin^eLD> how would that work and what would it allow us to do differently?
[07:01:15] <rmu> http://linuxcnc.org
[07:01:45] <rmu> you have complete control what S does
[07:02:12] <Jin^eLD> first paragaph sounds interesting, thank you
[07:02:29] <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
[07:03:32] <Jin^eLD> hmm, that sounds like a possible way
[07:03:51] <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
[07:07:20] <rmu> i think you can use iocontrol iopins like in toolchange to communication to HAL
[07:08:00] <Jin^eLD> oh, you mean pretend we are switching tools which would kind of "stop the spindle"?
[07:08:37] <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
[07:09:00] <Jin^eLD> would those iocontrol things allow to do that?
[07:09:14] <rmu> no i mean you connect you component not to motion.spindle-speed but to motion.analog-out-whatever
[07:09:20] <Jin^eLD> oh
[07:09:31] <rmu> and that value you can control from your remapped python code
[07:09:48] <Jin^eLD> our comp is C, but I assume that could also be controlled in C
[07:09:59] <rmu> and connect that value to your C comp
[07:10:04] <rmu> via HAL
[07:10:25] <Jin^eLD> oh ok, so some kind of a python proxy
[07:11:28] <rmu> yes, a kind of python shim that generates the info your toolchanger component needs
[07:11:38] <rmu> s/toolchanger/gearchanger/
[07:11:52] <Jin^eLD> sounds like a bit of overhead but could work as well
[07:11:59] <Jin^eLD> ok so we have identified 3 options for now
[07:12:33] <Jin^eLD> 1. do it silently in the comp, dont tell linuxcnc, 2. remap g-code 3. use motion.analog-out* with python proxy
[07:13:04] <rmu> 3 implies 2
[07:13:54] <Jin^eLD> right...
[07:14:26] <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
[07:14:36] <Jin^eLD> bbl :)
[07:14:41] Jin^eLD is now known as Jin|away
[07:17:39] <rmu> ttyl
[07:34:18] -!- selroc has joined #linuxcnc-devel
[07:36:16] -!- selroc has quit [Client Quit]
[08:22:22] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15dngarrett pushed 1 new commit to 06master: 02 https://github.com/LinuxCNC/linuxcnc/commit/76831229366a058b1b9030bcb4ed3c888d8c09ff
[08:22:22] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 147683122 15Dewey Garrett: motion.9 man page update...
[08:23:01] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15dngarrett 04deleted 06dgarr/motion_manpage at 14ade7ad5: 02 https://github.com/LinuxCNC/linuxcnc/commit/ade7ad5
[10:31:45] -!- Roguish has joined #linuxcnc-devel
[10:35:11] -!- Roguish has quit [Client Quit]
[10:37:50] <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.
[10:46:15] <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:52:36] -!- Roguish has joined #linuxcnc-devel
[11:02:34] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley pushed 2 new commits to 06qt5vcp_py2: 02 https://github.com/LinuxCNC/linuxcnc/compare/b8e42c02863f...c45478682507
[11:02:34] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06qt5vcp_py2 144ed3436 15Chris Morley: qtvcp -add probe more icons
[11:02:34] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06qt5vcp_py2 14c454786 15Chris Morley: qtvcp -update to most current widget design
[11:05:31] <Roguish> CMorley: good morning. how can I checkout (see) what you're working on?
[11:06:00] <Roguish> a git pull or something?
[11:07:11] <CMorley> qt5vcp_py2 is the current working branch. - you would need to checkout that branch.
[11:47:28] -!- jthornton has quit [Quit: Leaving]
[11:48:16] -!- jthornton has joined #linuxcnc-devel
[11:48:19] <rmu> re. halscope: wouldn't it be possible to reuse something like sigrok?
[11:48:46] <rmu> sigrok pulseview
[11:54:17] -!- jthornton has quit [Quit: Leaving]
[12:06:01] <skunkworks> well - it has to look and work exactly the same as halscope.. otherwise I won't like it.
[12:06:05] <skunkworks> ;)
[12:09:31] <hazzy-m> sigrok looks nice
[12:09:32] -!- jthornton has joined #linuxcnc-devel
[12:11:55] -!- jthornton has quit [Remote host closed the connection]
[12:12:54] <rmu> there is a lot that could be improved in halscope ;)
[12:15:52] <skunkworks> Oh - certianly - I am kidding
[12:16:20] -!- jthornton has joined #linuxcnc-devel
[12:23:57] <hazzy-m> rmu: skunkworks might rely on some of HALScope's idiosyncrasies ...
[12:23:58] <hazzy-m> https://xkcd.com
[12:29:39] <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.
[12:41:07] -!- jthornton has quit [Remote host closed the connection]
[12:54:26] <skunkworks> heh - no. Halscope works as expected
[12:59:14] -!- jthornton has joined #linuxcnc-devel
[12:59:34] -!- jthornton has quit [Remote host closed the connection]
[13:01:10] -!- jthornton has joined #linuxcnc-devel
[13:20:51] -!- jthornton has quit [Remote host closed the connection]
[13:21:50] -!- jthornton has joined #linuxcnc-devel
[13:26:57] -!- jthornton has quit [Remote host closed the connection]
[13:27:51] -!- jthornton has joined #linuxcnc-devel
[13:42:35] -!- ve7it has joined #linuxcnc-devel
[13:45:35] <rmu> it should not be that hard to connect the halscope realtime component to sigrok
[14:12:01] <jepler> skunkworks: I dabbled once or twice with replacing halscope, but I was too ambitious and never got anywhere
[14:12:22] <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.
[14:12:33] <jepler> oh hey rmu just said that
[14:12:37] * jepler hides again
[15:38:22] -!- jthornton has quit [Remote host closed the connection]
[15:39:20] -!- jthornton has joined #linuxcnc-devel
[15:54:50] -!- alex_joni has quit [Ping timeout: 250 seconds]
[17:01:43] -!- jthornton- has joined #linuxcnc-devel
[17:01:44] -!- jthornton has quit [Read error: Connection reset by peer]
[17:12:02] -!- andypugh has joined #linuxcnc-devel
[17:36:09] -!- jthornton- has quit [Read error: Connection reset by peer]
[17:36:22] -!- jthornton has joined #linuxcnc-devel
[17:37:49] -!- jthornton has quit [Read error: Connection reset by peer]
[17:39:54] -!- jthornton has joined #linuxcnc-devel
[17:40:12] -!- jethornton has joined #linuxcnc-devel
[17:41:37] -!- jethornton has quit [Client Quit]
[17:41:57] -!- jthornton- has joined #linuxcnc-devel
[17:46:28] -!- jthornton- has quit [Client Quit]
[18:02:49] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15andypugh pushed 1 new commit to 062.7: 02 https://github.com/LinuxCNC/linuxcnc/commit/7a150fcab35f0214b83079ab224b81af45d5f0c9
[18:02:49] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/062.7 147a150fc 15andy pugh: mux-generic: Fix the mux test results to suit the new, more functional,...
[18:28:19] <jepler> hum I guess the one I recently did some fixes on was demux
[18:28:21] <jepler> and in master only
[18:28:30] <jepler> and "recently" = a month or more ago
[18:40:07] <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
[18:40:21] <andypugh> (Dewey, I mean) Sorry Dewey
[18:43:04] <rene_dev_> andypugh huge merge conflict incoming...
[18:43:28] <andypugh> Reverse run?
[18:46:26] <rene_dev_> andypugh no, but thats also on the todo list...
[18:46:42] <rene_dev_> https://github.com
[18:47:12] <rene_dev_> still to be tested, but fixes at least 2 bugs
[18:47:52] <andypugh> Ah, but big multispindle merge problems?
[18:48:04] <andypugh> Going in 2.7?
[18:48:06] <rene_dev_> no, as its based on 2.7
[18:48:17] <rene_dev_> yes
[18:48:20] <andypugh> Then I guess I can manually merge it
[18:48:25] <andypugh> (to master)
[18:48:39] <rene_dev_> problems will come when it goes into master... but still needs testing
[18:48:50] <rene_dev_> https://github.com
[18:48:58] <rene_dev_> https://github.com
[18:49:03] <rene_dev_> should fix those bugs
[21:07:07] -!- andypugh has quit [Quit: andypugh]
[22:00:52] -!- c-log has quit [Ping timeout: 272 seconds]
[22:02:30] -!- c-log has joined #linuxcnc-devel