#linuxcnc-devel | Logs for 2018-09-04

Back
[01:02:07] -!- c-log has quit [Ping timeout: 240 seconds]
[01:08:00] -!- c-log has joined #linuxcnc-devel
[01:56:31] -!- ve7it has quit [Remote host closed the connection]
[02:22:17] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #283: Hi @c-morley,... 02https://github.com/LinuxCNC/linuxcnc/pull/283#issuecomment-418254015
[03:09:02] -!- selroc has joined #linuxcnc-devel
[03:21:05] -!- rob_h has joined #linuxcnc-devel
[03:47:25] -!- c-log has quit [Ping timeout: 246 seconds]
[03:48:31] -!- Whiskey24 has joined #linuxcnc-devel
[03:49:21] -!- c-log has joined #linuxcnc-devel
[03:51:20] -!- Whiskey24 has quit [Remote host closed the connection]
[03:58:29] -!- dp313 has joined #linuxcnc-devel
[04:04:04] -!- dp313 has quit [Remote host closed the connection]
[04:50:51] -!- linuxmodder15 has joined #linuxcnc-devel
[04:55:47] -!- linuxmodder15 has quit [Ping timeout: 240 seconds]
[05:06:04] -!- rob_h has quit [Ping timeout: 272 seconds]
[05:18:52] -!- LambdaComplex28 has joined #linuxcnc-devel
[05:21:41] -!- LambdaComplex28 has quit [Remote host closed the connection]
[05:27:28] -!- selroc has quit [Quit: Leaving]
[07:41:28] -!- theresajayne16 has joined #linuxcnc-devel
[07:44:22] -!- theresajayne16 has quit [Remote host closed the connection]
[08:11:04] -!- rob_h has joined #linuxcnc-devel
[09:20:47] -!- rob_h has quit [Ping timeout: 240 seconds]
[09:24:58] <Jin^eLD> I have a question on handling spindle speed changes...
[09:25:11] <Jin^eLD> lets assume the machine has a gearbox and supports only certain speeds
[09:25:37] <Jin^eLD> if someone has a UI with a slider, the speed pin gets updated during the movement of that slider
[09:26:10] <Jin^eLD> so question is when would the best point be to start shifting?
[09:26:30] <Jin^eLD> (taking into account that the speed requested needs to be quantized to the supported value)
[09:27:05] <Jin^eLD> I wish there was a way to bind a pin to a "slider released" event
[09:27:26] <Jin^eLD> this would mean the user finished moving the slider and picked the desired speed
[09:28:01] <Jin^eLD> any hints or thoughts on that? how are such scenarios currently handled?
[09:47:50] <cradek> I think it's a mistake to change gears based only on the spindle speed number.
[09:48:13] <Jin^eLD> what should the decision be based on then?
[09:49:52] <cradek> an explicit direction from the user, in some convenient way
[09:50:57] <Jin^eLD> I thought that the motion interface was this explicit direction, i.e., via spindle_speed_in_abs ? So am I mistaken to treat the motion interface as some sort an API?
[09:51:41] <cradek> consider that many gearboxes have overlapping ranges, and you might want to pick one or the other based on what else is happening (like tapping vs cutting)
[09:52:01] <cradek> or you want to tap in a certain range, but when the tap slows and reverses you absolutely don't want a gear change
[09:52:10] <Jin^eLD> but how would that work in combination with gcode? I thought that runs automated?
[09:52:17] <cradek> or that you should be able to stop in any gear without switching to the lowest gear
[09:52:38] <cradek> unfortunately you have to be creative because there is no standard gcode for gear selection
[09:52:41] <cradek> brb
[09:53:10] <Jin^eLD> hmmm
[09:55:27] <Jin^eLD> are there any such machines/examples already in LinuxCNC, i.e. to look at them as reference?
[09:56:11] <mozmck> Jin^eLD: are there variable speed ranges for each gear, or is each gear a fixed speed?
[09:56:25] <Jin^eLD> there are 18 fied speeds
[09:56:28] <Jin^eLD> *fixed
[09:56:48] <mozmck> Either way, I think you could make a HAL component that would select the gear based on an input speed from motion.
[09:57:10] <Jin^eLD> well that is what I am doing right now, not much is misssing
[09:57:15] <Jin^eLD> we'll probably start testing soon
[09:57:48] <Jin^eLD> but we noticed that there may be a problem with the slider
[09:58:03] <mozmck> Are you using pyvcp?
[09:58:37] <Jin^eLD> for testing/simulation - yes, for the real environment I think my friend is using gmocappy or something?
[09:58:54] <Jin^eLD> I'm a coder, he has the machine :) so I'm just helping him and coding the component for him
[09:59:27] <Jin^eLD> I made myself two components, one to simulate the machine + pyvcp control UI, and the other is the real component that we will hook to the mill once I feel that its ready
[09:59:44] <mozmck> In python you can make a slider update the hal pin only on a release event, and you could also make it snap to a fixed speed closest to the requested speed.
[09:59:48] <Jin^eLD> in his "real"UI he has a slider as well
[10:00:20] <Jin^eLD> did I miss that in the pyvcp docs? or did you mean in python as in "python component"?
[10:00:27] <Jin^eLD> we have a C realtime component
[10:00:47] <Jin^eLD> and I use pyvcp just to simulate some user input and machine states
[10:01:18] <mozmck> I don't know much about pyvcp, but I've done work using gscreen and I think I've done something like this there. Gmoccapy is similar to gscreen and is written in python.
[10:02:13] <Jin^eLD> ok so at least in "his" UI he could handle that by using the release event, thats good to know
[10:03:07] <Jin^eLD> still I am now a bit unsure how to deal with cradek's feedback, I thought those speed requests were standardized via some API or something, ok I have to admit I am new to LinuxCNC, but I did read the docs etc
[10:03:48] <mozmck> Yeah, the UI uses glade, and handles events in python code.
[10:04:30] <Jin^eLD> OK so that part would not be a real problem then
[10:04:50] <Jin^eLD> still I wonder if my decision to base the speed choice on spindle_speed_in_abs is correct
[10:05:00] <Jin^eLD> cradek indicated that might not be a good idea
[10:05:02] <mozmck> I think cradek was thinking of something where you have a couple of gears and a variable pulley setup. So you might have 2 or 3 ranges, and variable speed in each range.
[10:05:21] <Jin^eLD> and of course second thing: if someone decided to input several speed changes quickly - I will ignore all changes until I finish the gearshift I started
[10:05:22] <mozmck> And some overlap in speeds
[10:05:34] <Jin^eLD> aha
[10:05:45] <Jin^eLD> no, we have really fixed 18 speeds
[10:05:54] <Jin^eLD> lowest gear is 80 rpm, highest 4000
[10:06:02] <mozmck> Yeah, so any speed change = gear change.
[10:06:29] <Jin^eLD> well, only if the speed is quantized already...
[10:06:45] <Jin^eLD> otherwise I do the mappings
[10:06:54] <Jin^eLD> so next is 100
[10:07:07] <Jin^eLD> if someone picks 1 to 90 I will quantize tha to 80
[10:07:13] <mozmck> yes, I'm guessing you'll do something like rounding a float to int
[10:07:30] <Jin^eLD> yes and then picking the closest possible gear
[10:07:35] <mozmck> yep
[10:08:31] <mozmck> have you looked at the spindle-at-speed stuff? I have not done much with spindles at all, but I remember that there is a pin or something to prevent further motion until the spindle is at speed.
[10:09:11] <Jin^eLD> I guess I missed that one, thank you! that may very well be the thing I was looking for
[10:09:45] <mozmck> I would think you want something like that to pause everything until the gear gets changed at least.
[10:10:12] <Jin^eLD> yes, this was exactly my concern - if someone starts sending me speeds, but I can not handle them because I'm busy shifting
[10:10:59] <mozmck> http://linuxcnc.org
[10:11:48] <mozmck> https://forum.linuxcnc.org
[10:12:40] <Jin^eLD> thats the pin, thank you :)
[10:13:12] <mozmck> There is also a motion.feed-inhibit pin that might be useful if that does not do exactly what you need.
[10:13:18] <mozmck> you're welcome!
[10:13:47] <Jin^eLD> curious if that all will work out in the end :) my first component
[10:22:40] <cradek> mozmck: you're right about my assumptions - I would have to think about how fixed gears should work
[10:23:02] <cradek> gcode doesn't really match it very well, does it
[10:23:23] <cradek> and spindle override percentage doesn't match it very well either
[10:23:27] <Jin^eLD> people who have that mill and run it on the native philips controller had to prepare gcode to only send supported speeds
[10:23:35] <Jin^eLD> otherwise it would refuse the code
[10:23:52] <cradek> well that's one way to do it :-)
[10:24:09] <Jin^eLD> with LinuxCNC we of course were hoping to improve on that ;)
[10:24:41] <Jin^eLD> so I map any input to the closest supported gear/speed
[10:26:10] <mozmck> The only issue I can see is that possibly if the feedrate is set for a certain spindle speed - say 1200 rpm; but the closest thing is 1000 rpm, then the feedrate may be too fast for the slower spindle speed.
[10:26:47] <mozmck> I think a higher spindle speed generally won't hurt though.
[10:26:50] <cradek> you mean like if using fpr? is this a lathe?
[10:27:22] <mozmck> Jin^eLD said "people who have that mill", so I think it's a mill?
[10:27:28] <cradek> ah
[10:27:38] <mozmck> I assume the same would be true of a lathe also though.
[10:27:53] <Jin^eLD> its a MAHO MH400E mill
[10:28:06] <Jin^eLD> my buddy asked me to lean to lower speeds
[10:28:18] <Jin^eLD> i.e. when something is right down the middle, I chose the lower gear
[10:28:52] <Jin^eLD> but that would be easy to tune I guess
[10:28:54] <mozmck> Huh, ok. You might mention that to him though - he should know if he is a machinist!
[10:29:04] <Jin^eLD> I will tell him
[10:32:47] <Jin^eLD> that spindle-at-speed pin - this is only for LinuxCNC right? or should it be connected to the machine too?
[10:32:53] <Jin^eLD> he tells me:
[10:32:55] <Jin^eLD> I can't provide an input to that pin, as there is no encoder on the
[10:32:55] <Jin^eLD> spindle. The closest thing on the MAHO is the Spindle _stopped.
[10:33:21] <Jin^eLD> I think he expects that this pin needs to be connected to the machine as well, but I understood it only signals LinuxCNC?
[10:34:33] <cradek> that pin is to tell linuxcnc it can continue because the spindle is done changing speed. if you don't connect it to anything, linuxcnc will just continue after a speed change without waiting for anything.
[10:34:58] <Jin^eLD> got it
[10:35:04] <cradek> but you probably should use it to signal to linuxcnc that whatever gear changing is done, because you don't want to go on cutting while the gears are changing
[10:35:06] <Jin^eLD> so thats indeed what we need
[10:35:12] <cradek> yes
[10:36:33] <Jin^eLD> thanks guys :)
[10:39:15] -!- drdanick23 has joined #linuxcnc-devel
[10:42:05] -!- drdanick23 has quit [Remote host closed the connection]
[11:33:24] -!- woodface has joined #linuxcnc-devel
[11:34:06] -!- woodface has quit [Remote host closed the connection]
[12:33:16] <rene_dev_> thanks seb_kuzminsky :)
[12:35:52] -!- MJ941 has joined #linuxcnc-devel
[12:38:40] -!- MJ941 has quit [Remote host closed the connection]
[13:09:50] <skunkworks> we do that on the K&T. 16 gears
[13:10:08] <skunkworks> we also make it so spindle override doesn't try to change gears...
[13:13:07] <Jin^eLD> skunkworks: what speed do you report back after quantizing? the real one, right?
[13:13:21] <Jin^eLD> i.e. its not a problem if someone requested 85 but we were only able to set 80 and report back 80?
[13:19:34] -!- rob_h has joined #linuxcnc-devel
[13:24:59] <skunkworks> the real one
[13:25:16] <skunkworks> I have a vfd + gears so I can run any speed
[13:26:18] <skunkworks> (don't laugh)
[13:26:20] <skunkworks> http://electronicsam.com
[13:27:11] <Jin^eLD> yeah, wanted to ask... why have both if you are able to shift? afaik most who have a vfd put the gearbox into one gear and leave it like that
[13:27:17] <Jin^eLD> :)
[13:28:33] <Jin^eLD> either the tabs are messed up in the browser or you have an unorthodox coding style =)
[13:28:57] <Jin^eLD> I'm surprised how short it is, the MAHO seems a lot more complicated
[13:29:45] <Jin^eLD> I'm already at over 1100 lines of code
[13:44:23] <skunkworks> it is unorthadox coding style
[13:44:45] <Jin^eLD> :)
[13:44:45] <skunkworks> it has been pretty solid. I cannot think of any issues
[13:45:06] <Jin^eLD> on the MAHO you have three motors which you have to activate in sequence to move gears on each shaft of the gearbox
[13:45:13] <Jin^eLD> a loogical pain
[13:45:17] <Jin^eLD> *logical
[13:45:40] <Jin^eLD> depending on where you go you need to know when to reverse the motors or when to apply a lowspeed pin so it does not overshoot a gear
[13:45:50] <skunkworks> https://www.youtube.com
[13:45:57] <Jin^eLD> I am really curious how it will work out in reality, so far I am coding vs the "spec" that we came up with
[13:46:15] <Jin^eLD> sorry can't watch, I am on a traffic limited mobile connection :P
[13:46:36] <skunkworks> 4 shift rails - it senses the rail pressure to see if they have enguages..
[13:47:24] <skunkworks> engaged
[13:47:40] <skunkworks> (slowly rotates counter clockwise to shift)
[13:48:48] <skunkworks> seems to me someone has already done it.. for a maho
[13:49:30] <Jin^eLD> there were several attempts, but it depends on the version, some of the MAHOs have a vfd which makes things a lot easier
[13:49:32] <skunkworks> sorry video https://www.youtube.com
[13:49:51] <Jin^eLD> do you have a photo? I really can't watch videos here, traffic :P
[13:50:18] <Jin^eLD> we have a few pictures here: https://github.com and also two video links which I also did not have to chance to watch so far
[13:50:39] <Jin^eLD> there was a czech student who did a component for the MH500 I think, but thats the vfd version
[13:51:16] <Jin^eLD> and a guy in the forums started a component for the MH700 which is somewhat similar to the MH500, but afaik he sold his machine and did not finish the comp
[13:51:25] <Jin^eLD> aehm, simiular to the MH400 I mean
[13:51:33] <Jin^eLD> doh, my typing..
[13:52:44] <seb_kuzminsky> rene_dev_: welcome aboard! :-)
[14:32:22] -!- ve7it has joined #linuxcnc-devel
[15:13:41] <Jin^eLD> one more question about spindle_at_Speed - when would be the best time to set it to false again?
[15:14:01] <Jin^eLD> easiest of course, before starting a gearshift, but I am not sure if thats not too late, forum says:
[15:14:11] <Jin^eLD> Once the at speed signal goes true the machine will not pause again if it later goes false, unless a spindle speed change or start is commanded.
[15:14:55] <Jin^eLD> "unless a spindle speed change or start is commanded" - so setting it false right before a gearchange is too late
[15:15:01] <Jin^eLD> ?
[16:01:52] <KimK> Jin^eLD: Sorry if I'm kibitzing again, but be careful not to confuse spindle-at-speed and spindle-at-zero. They are not just complements of each other.
[16:02:28] <Jin^eLD> I did not look at spindle-at-zero yet to ehonest
[16:02:37] <Jin^eLD> but I assume you mention it for a reason? I will read up on it
[16:04:55] <Jin^eLD> but my original question still stands, so any input on that would be helpful :)
[16:08:17] <Jin^eLD> where does spindle-at-zero come rom, I do not see it in the motion docs?
[16:08:20] <Jin^eLD> http://www.linuxcnc.org
[16:10:11] <KimK> Spindle-at-speed has more to do with waiting in-cycle for the spindle to ramp up before starting to cut. Or, maybe last-ditch, if you've dug in so hard that you're pulling the spindle down, stop moving a bit and regain control? (Your hand should already be flying toward the feedhold.)
[16:10:55] <KimK> Spindle-at-zero is an output that comes from the spindle drive usually, or maybe a stand-alone detector box of some kind.
[16:15:04] <KimK> Spindle-at-zero is not really zero, but says whether the spindle speed is above or below a very low threshold. It can be set to whatever is convenient for that machine. Some gearboxes have to be absolutely stopped to shift (sometimes with an auxillary "spindle jog" motor drive), some have to be rotated at a low rate ("creep speed") to shift. The spindle-at-zero can be involved to whatever degree is desired, builder's choice.
[16:16:24] <Jin^eLD> aha, interesting
[16:17:03] <Jin^eLD> well in our case it should really be zero, I'm supposed to enter a special twitching mode to twitch the spindle back and forth while I shift the gears so that they mesh properly (straight teeth gears)
[16:18:10] <Jin^eLD> if our spindle-at-zero value is indeed zero - does it make sense to provide that pin? probably not?
[16:18:18] <KimK> OK, so you have a gearbox of the "stop and then activate spindle jogger (oscillator)" tyep
[16:18:31] <KimK> s/tyep/type/
[16:18:45] <Jin^eLD> yes, only that I have no oscillator but have to actually code it :)
[16:18:51] <KimK> OK.
[16:19:00] <Jin^eLD> I have two pins for twitch cw/twitch ccw and have to alternate myself
[16:19:15] <Jin^eLD> but I start only once the spindloe is stopped
[16:19:41] <Jin^eLD> the machine provides such a pin so I can check
[16:20:16] <KimK> You may want to include that timer I mentioned. Start jogging after stop indicated plus 300ms or some such.
[16:21:31] <Jin^eLD> ok wait, the jogging oscilator is a LinuxCNC thing?
[16:21:37] <Jin^eLD> I may have misunderstood you
[16:21:47] <Jin^eLD> I thought you were thinking the machine provided such an oscillator
[16:22:57] <KimK> You can get the jogging any way you like. If the machine has a spindle drive mode that does that already, fine. If the spindle drive has become cantankerous and has been replaced with a vanilla drive, that's OK too, it's still possible to do.
[16:23:38] <KimK> Do you have a machine manual and schematics?
[16:24:03] <Jin^eLD> yes, my friend - thats who owns the machine and whom I am helping on the software side, got schematics from MAHO
[16:24:46] <KimK> Excellent. Then you can look at the spindle drive control I/O and see if there's anything unusual there.
[16:24:51] <Jin^eLD> he mostly came up with a "spec" on what the machine eppects
[16:25:05] <Jin^eLD> and told me which pins I should use and what they do
[16:25:49] <Jin^eLD> and for twitching, he told me the two pins that I am supposed to use
[16:26:02] <Jin^eLD> so I guess tahts fine
[16:26:15] <KimK> These are all pins on the original Maho spindle drive?
[16:26:16] <Jin^eLD> what I am not yet fully clear about is when to de-energize spindle-at-speed
[16:27:03] <Jin^eLD> thats how I understood it
[16:27:22] <KimK> You observe spindle-at-speed, it's an output from the spindle drive (or a black box).
[16:28:12] <Jin^eLD> well, yes, but the reason for my question was this line from the forum:
[16:28:14] <Jin^eLD> Once the at speed signal goes true the machine will not pause again if it later goes false, unless a spindle speed change or start is commanded
[16:28:15] <KimK> You may not get spindle-at-speed during jogging though, consult yoour drive manual.
[16:28:37] <KimK> s/yoour/your/
[16:28:40] <Jin^eLD> so I need to tell LinuxCNC when I am ready with my gearshift
[16:28:44] <Jin^eLD> that I understand, but then later
[16:28:49] <Jin^eLD> I need to reset the pin back to false
[16:29:03] <Jin^eLD> and I am not sure when the best point for that would be, considering the line from the forums
[16:32:04] <KimK> A pause for spindle-at-speed is (generally) a pause for the spindle to ramp up before continuing with the g-code (i.e., starting to cut). Say it takes your machine 5 seconds to come up to speed (assuming already in correct gear), once it comes up to speed, you're done waiting, continue with gcode. You only have to wait again if there's another spindle speed change. Does that help?
[16:34:07] <Jin^eLD> OK, but the above describes when to set that pin to true, or am I misunderstanding?
[16:34:24] <Jin^eLD> I Did the gearshift, I waited for it to come up to speed, I trigger the pin so g-code can continue cutting
[16:34:54] <Jin^eLD> right?
[16:35:01] <Jin^eLD> and now - when do I set it back to flase?
[16:35:15] <KimK> Same on the way down, after M5 it waits for spindle-at-speed (which now happens to be zero, but nevermind) and then (after 5 second ramp-down) executes the M30/M2 and is done.
[16:35:19] <Jin^eLD> just leave it high for some small amount of time and then reset it?
[16:36:15] <KimK> All this should happen automatically via your setup, HAL, ClassicLadder, external devices, whatever.
[16:36:35] <KimK> I guess your component in this case?
[16:37:03] <Jin^eLD> yes, sorry if I was not clear :)
[16:37:18] <Jin^eLD> by asking "when do I set it back to false" I meant, when do I decide to do that in the component
[16:37:28] <Jin^eLD> assuming that I did the steps above and set it true to signal I am ready
[16:38:07] <Jin^eLD> just keep it true for dunno, 500ms? 1s? and then automatically set it back to false?
[16:38:13] <KimK> But you're just sending the spindle-at-speed signal from the spindle drive(?) to the LinuxCNC apindle-at-speed input. You don't know what it is, and you don't care.
[16:38:57] <Jin^eLD> uhm...?
[16:39:15] <KimK> Unless you *do* care because you're taking over manually for some reason (jogging?).
[16:40:06] <Jin^eLD> from the discussions I had here earlier, where I was told to use that pin, I understood that I use it in order to notify LinuxCNC when I am done with gearshifting, because it will wait for me until I raise spindle-at-speed?
[16:40:36] <Jin^eLD> i.e. I need it so that LinuCNC knows it can continue, that a requested speed change was done and the machine is ready
[16:41:25] <cradek> it should be true when the spindle is turning at the specified speed, and false otherwise
[16:42:21] <Jin^eLD> cradek: i.e. if (current_speed == spindle_speed_in_abs) then spindle_at_speed = true; ?
[16:42:26] <cradek> so you should set it false when something changes that makes it so the spindle is no longer turning at the requested speed
[16:42:47] <Jin^eLD> ok, I think now I got it
[16:42:48] <cradek> I don't know why you'd use timers etc for this
[16:43:17] <Jin^eLD> I misunderstood how it works, now that you explained it again from this angle, I understand
[16:43:24] <cradek> cool
[16:44:12] <KimK> timers for "smoothness" because sometimes the stopped indication comes in below, say, 50 RPM, but it'
[16:44:17] <KimK> oops
[16:45:00] <KimK> timers for "smoothness" because sometimes the stopped indication comes in below, say, 50 RPM, but it's still moving, so adding a few 100ms to give it time to "really" stop eliminates grinding (if it does).
[16:45:58] <seb_kuzminsky> i use a `comp` for that, as long as the value is within some hysteresis it's ok, if it goes outside that it's bad
[16:46:04] <KimK> but the timer is just a delay from the actual signal, not a substitute for the actual signal
[16:46:16] <seb_kuzminsky> http://linuxcnc.org
[16:46:46] <cradek> seb_kuzminsky: his machine has N fixed-speed gearings
[16:47:05] <seb_kuzminsky> oh, right
[16:52:11] <KimK> Jin^eLD: Have we got you totally confused now?
[16:52:34] <Jin^eLD> :)
[16:52:52] <Jin^eLD> no,. I think cradeks final explanation was fine
[16:53:22] <Jin^eLD> and made me think of how we can implement that, because that showed me that its not enough just to shift the gear, I need to know that the spindle is back on and turning
[16:53:33] <Jin^eLD> and spindle control is currently outside of the comp
[16:53:46] <Jin^eLD> I only have a pin that tells me if it stopped
[16:54:01] <Jin^eLD> I already wrote my friend to check this
[16:54:22] <Jin^eLD> some of you may know him from the forum, it's rotarySMP/Mark whom I am helping
[17:02:20] -!- Joral_ has joined #linuxcnc-devel
[17:02:21] -!- Joral_ has quit [Client Quit]
[17:02:55] -!- Joral has joined #linuxcnc-devel
[17:03:35] -!- Joral_ has joined #linuxcnc-devel
[17:06:00] <Joral> hello, i am currently trying to set up a linuxcnc machine and discovered a couple of edits that I cannot figure out how to commit upstream. I currently have linuxcnc built and running on ubuntu 18.04 with only three edits to the main source tree.
[17:06:49] -!- Joral_ has parted #linuxcnc-devel
[17:29:43] <JT-Shop> I think you need to do a pull request
[17:30:55] <Joral> JT-Shop, the changes are part of the package control file and git isn't recognizing the changes. says there is nothing to pull
[17:31:38] <JT-Shop> did you change the .gitignore file so git can see the changes?
[17:32:10] <Joral> JT-Shop nope, new to git so I didn't know to change that lol
[17:32:54] <JT-Shop> yea anything in .gitignore is ignored by git, I like to use git gui
[17:33:05] <Jin^eLD> you can commit files in .gitignore by using -f (force)
[17:33:09] <seb_kuzminsky> Joral: debian/control is generated from debian/control.* by debian/configure
[17:33:20] <seb_kuzminsky> debian/control itself is not in our git
[17:33:29] <seb_kuzminsky> that's why it's not showing the change you made to it
[17:33:59] <Joral> seb_kuzminsky, gotcha, so how would we edit to show that the new package names still meet the dependencies?
[17:34:35] * JT-Shop is glad seb chimed in it was getting over my head
[17:35:26] <Joral> one is that python-imaging is now called python-pil and the other two issues are because gstreamer hardcodes the package version in the package name so gstreamer1.0 !+ gstreamer0.10
[17:35:54] <seb_kuzminsky> you should find the debian/control.* file that has the part you want to change, change it in that file, run debian/configure to generate debian/control, verify that the generated debian/control has the correct contents, then commit the changes you made
[17:36:14] <seb_kuzminsky> some of the stuff is in debian/configure too, so you might have to change things in there
[17:36:22] <seb_kuzminsky> it's got all the distro-specific stuff
[17:37:02] <seb_kuzminsky> then here are the docs for how to get the changes into mainline: http://linuxcnc.org
[17:37:42] <seb_kuzminsky> the short of it is: fork us on github, commit your local changes to a branch, push to your github fork, and send us a PR
[17:39:17] <Joral> ok, i will work on that
[17:39:21] <seb_kuzminsky> cool!
[17:39:34] <seb_kuzminsky> and feel free to ask more detailed questions here, someone will help out
[17:41:59] <Joral> also is there a functional difference between the rt kernel and the lowlatency kernel, or is lowlatency what debian is calling the kernel with the rt hooks
[17:42:22] <seb_kuzminsky> i think lowlatency is the normal kernel.org kernel, with the config tuned to minimize latency
[17:42:43] <seb_kuzminsky> the rt kernel is the kernel.org kernel *with* the rt-preempt patches, then configured to minimize latency
[17:42:58] <seb_kuzminsky> so the rt kernel will have *much* better latency than the lowlatency kernel
[17:43:11] <seb_kuzminsky> the lowlatency kernel is not what linuxcnc would consider a realtime kernel
[17:43:26] <Joral> ok, different question here then, will the linuxcnc build fail without a rt kernel?
[17:43:53] <seb_kuzminsky> it depends on how you configure linuxcnc
[17:44:06] <Joral> not building sim but full linuxcnc
[17:44:06] <seb_kuzminsky> in src/configure, if you say --with-realtime=uspace, it'll build on any kernel
[17:44:15] <jepler> for "uspace" to run with realtime (A) rtapi_app has to be setuid root (B) uname has to have "PREEMPT RT" in it and (C) "/sys/kernel/realtime" has to exist. You can relax B and C by editing the source code.
[17:44:25] <Joral> ah, the uspace doesn't check the kernel
[17:44:29] <jepler> see detect_preempt_rt
[17:44:39] <seb_kuzminsky> a wild jepler appears!
[17:44:49] <jepler> (uspace will also try to run on rtai and xenomai depending on compile-time options)
[17:44:57] <seb_kuzminsky> see Joral , talking about uspace brings him out of hiding
[17:44:58] <jepler> (but that's just a curiosity and I don't recommend using it)
[17:45:36] <Joral> thats how I got it to build on lowlatency then i was using uspace with xenomai
[17:47:15] <jepler> I don't know whether any kernel provided by ubuntu is suitable for running linuxcnc these days. debian stretch has PREEMPT RT kernels and they work well on a wide range of hardware.
[17:49:36] <Joral> im not opposed to building my own kernel, but in ubuntu apt freaks out that there are updates if you aren't letting apt manage kernels. I would be thrilled if I could build for gentoo, but with the only installable build being through dpkg Im kind of at a loss of what makes the most sense to do.
[17:51:34] <seb_kuzminsky> we've had some interest in a gentoo build, but so far no one has gone all the way through building a gentoo rt kernel and making a linuxcnc ebuild
[17:52:01] <seb_kuzminsky> i wonder if the debian rt kernel would install on ubuntu?
[17:52:22] <Joral> seb_kuzminsky, the kernel is part of the system setup and wouldn't be part of the ebuild.
[17:52:46] <Joral> that was my next question, is there a ppa for the kernel to have it as a matched set?
[17:52:46] <seb_kuzminsky> right, it's in sys-kernel, and built by genkernel or by hand, as i understand it
[17:53:08] <seb_kuzminsky> we (linuxcnc) supply an rtai kernel for debian wheezy, from our repo
[17:53:22] <jepler> with uspace & preempt rt you're not tied to a single kernel. there are no kernel modules or other dependencies on kernel ABI.
[17:53:59] <jepler> but to be worth using it needs to actually give RT performance and have those items like uname and /sys entries that I mentioned above...
[17:55:04] <jepler> looks like our wiki has some stuff (maybe from 2017?) about an ebuild of linuxcnc (it says to build your own kernel though)
[17:56:18] <Joral> my issue (and i admit this is somewhat petty) is that I couldn't install any cad tools to go along with the wheezy install because it was so old it didn't support freecad or any others that I could find.
[17:56:30] <seb_kuzminsky> yeah :-/
[17:56:41] <seb_kuzminsky> dont tell anyone, but i run stretch/rt-preempt on all my machines
[17:56:56] <jepler> yeah we are too timid to properly announce it, but that's the only thing you should run
[17:57:47] <seb_kuzminsky> http://linuxcnc.org
[17:57:54] <Joral> we are trying to set up this old machine as a controller for a cnc router and while we will probably use fusion360 etc for major part dev, it would be nice to have an option right there in the shop to recalc toolpaths etc if needed
[17:59:15] <Joral> so silly question then, what is the new version of debian that ubuntu 18.04 is built on?
[17:59:41] <seb_kuzminsky> no idea
[17:59:52] <seb_kuzminsky> i stopped paying attention to ubuntu back in the 12.04 days
[18:00:01] <seb_kuzminsky> pure debian for me please
[18:02:53] <jepler> the internet tells me it's based on "buster / sid". buster was/is "testing" I think. sid is sid.
[18:03:21] <jepler> and that the file /etc/debian_version will spill the details for sure
[18:03:30] <seb_kuzminsky> yeah, buster is stretch+1
[18:04:55] <jepler> huh xenomai is working on ipipe-x86 for 4.14, so they're not totally done.
[18:05:06] <jepler> the branch is called "wip/4.14" so don't get your hopes too high
[18:08:17] Jin^eLD is now known as Jin|away
[18:08:24] <Jin|away> thanks for the help, nite!
[18:09:45] <Joral> so im on the debian website and im not seeing any way to pick a version. if you go to the download page the only link is for version 9.5, is that the newest?
[18:10:09] <seb_kuzminsky> yeah, 9 is stretch, .5 is the current "patch level" or whatever they call it
[18:11:17] <Joral> so stretch is what I want?
[18:11:27] <seb_kuzminsky> yes
[18:11:42] <seb_kuzminsky> you can install from debian.org's installer iso, or from the one i linked above that is preconfigured for linuxcnc
[18:12:31] <Joral> missed the link lol, thanks
[19:49:02] -!- Roguish has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
[20:04:09] -!- rob_h has quit [Ping timeout: 272 seconds]
[20:48:36] -!- robotustra has joined #linuxcnc-devel
[20:48:42] <robotustra> good night
[20:48:52] <robotustra> have a question about linuxcncrsh
[20:49:30] <robotustra> actually more than one
[20:50:26] <robotustra> 1) http://linuxcnc.org the example at the bottom of the page is not correct
[20:50:59] <robotustra> it's impossible to make "set mode manual" before "set estop off"
[20:52:59] <robotustra> 2) what is the right sequence of homing?
[20:53:38] <robotustra> when I do home x,y and then Z -I get an error message about "cannot home while shared home switch is closed"
[20:53:54] <robotustra> but if I home z,x,y everything is ok.
[20:54:02] <robotustra> is it bug of feature?
[20:56:13] <robotustra> and 3) When I execute a g-code file "set run", the "set pause" command is ignored. What should be done to be able to pasue execution?
[21:06:53] <robotustra> I got the answer to quesion 3 myself
[21:19:27] -!- robotustra has parted #linuxcnc-devel
[21:29:57] -!- wols2 has joined #linuxcnc-devel
[21:30:41] -!- wols2 has quit [Remote host closed the connection]
[21:44:49] -!- Tom_shop has joined #linuxcnc-devel
[22:11:59] -!- Tom_shop has quit [Quit: Leaving]
[22:26:30] -!- Joral has quit [Quit: Hello, 911? Yeah, it's caught in the window this time.]
[22:37:27] <jepler> robotustra: (1) submit a doc patch (2) a machine can be configured such that a single input pin is shared between 2 or more axes or joints. in this case, it imposes restrictions on the homing sequence. many sample inifiles are this way.
[22:45:21] -!- Khetzal has quit [Ping timeout: 260 seconds]
[22:46:48] -!- Khetzal has joined #linuxcnc-devel
[23:23:38] -!- hiya3 has joined #linuxcnc-devel
[23:26:13] -!- hiya3 has quit [Remote host closed the connection]
[23:57:44] -!- ve7it has quit [Remote host closed the connection]
[23:59:19] -!- ve7it has joined #linuxcnc-devel