#linuxcnc-devel Logs

Sep 04 2018

08:25 AM Jin^eLD: I have a question on handling spindle speed changes...
08:27 AM Jin^eLD: lets assume the machine has a gearbox and supports only certain speeds
08:27 AM Jin^eLD: if someone has a UI with a slider, the speed pin gets updated during the movement of that slider
08:27 AM Jin^eLD: so question is when would the best point be to start shifting?
08:27 AM Jin^eLD: (taking into account that the speed requested needs to be quantized to the supported value)
08:27 AM Jin^eLD: I wish there was a way to bind a pin to a "slider released" event
08:28 AM Jin^eLD: this would mean the user finished moving the slider and picked the desired speed
08:28 AM Jin^eLD: any hints or thoughts on that? how are such scenarios currently handled?
08:48 AM cradek: I think it's a mistake to change gears based only on the spindle speed number.
08:48 AM Jin^eLD: what should the decision be based on then?
08:50 AM cradek: an explicit direction from the user, in some convenient way
08:51 AM 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?
08:52 AM 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)
08:52 AM 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
08:52 AM Jin^eLD: but how would that work in combination with gcode? I thought that runs automated?
08:52 AM cradek: or that you should be able to stop in any gear without switching to the lowest gear
08:53 AM cradek: unfortunately you have to be creative because there is no standard gcode for gear selection
08:53 AM cradek: brb
08:53 AM Jin^eLD: hmmm
08:56 AM Jin^eLD: are there any such machines/examples already in LinuxCNC, i.e. to look at them as reference?
08:56 AM mozmck: Jin^eLD: are there variable speed ranges for each gear, or is each gear a fixed speed?
08:57 AM Jin^eLD: there are 18 fied speeds
08:57 AM Jin^eLD: *fixed
08:57 AM mozmck: Either way, I think you could make a HAL component that would select the gear based on an input speed from motion.
08:57 AM Jin^eLD: well that is what I am doing right now, not much is misssing
08:57 AM Jin^eLD: we'll probably start testing soon
08:58 AM Jin^eLD: but we noticed that there may be a problem with the slider
08:58 AM mozmck: Are you using pyvcp?
08:59 AM Jin^eLD: for testing/simulation - yes, for the real environment I think my friend is using gmocappy or something?
08:59 AM Jin^eLD: I'm a coder, he has the machine :) so I'm just helping him and coding the component for him
09:00 AM 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:00 AM 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:00 AM Jin^eLD: in his "real"UI he has a slider as well
09:00 AM Jin^eLD: did I miss that in the pyvcp docs? or did you mean in python as in "python component"?
09:01 AM Jin^eLD: we have a C realtime component
09:01 AM Jin^eLD: and I use pyvcp just to simulate some user input and machine states
09:01 AM 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.
09:02 AM Jin^eLD: ok so at least in "his" UI he could handle that by using the release event, thats good to know
09:03 AM 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
09:04 AM mozmck: Yeah, the UI uses glade, and handles events in python code.
09:05 AM Jin^eLD: OK so that part would not be a real problem then
09:05 AM Jin^eLD: still I wonder if my decision to base the speed choice on spindle_speed_in_abs is correct
09:05 AM Jin^eLD: cradek indicated that might not be a good idea
09:05 AM 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.
09:05 AM 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
09:05 AM mozmck: And some overlap in speeds
09:06 AM Jin^eLD: aha
09:06 AM Jin^eLD: no, we have really fixed 18 speeds
09:06 AM Jin^eLD: lowest gear is 80 rpm, highest 4000
09:06 AM mozmck: Yeah, so any speed change = gear change.
09:07 AM Jin^eLD: well, only if the speed is quantized already...
09:07 AM Jin^eLD: otherwise I do the mappings
09:07 AM Jin^eLD: so next is 100
09:07 AM Jin^eLD: if someone picks 1 to 90 I will quantize tha to 80
09:07 AM mozmck: yes, I'm guessing you'll do something like rounding a float to int
09:08 AM Jin^eLD: yes and then picking the closest possible gear
09:08 AM mozmck: yep
09:09 AM 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.
09:09 AM Jin^eLD: I guess I missed that one, thank you! that may very well be the thing I was looking for
09:10 AM mozmck: I would think you want something like that to pause everything until the gear gets changed at least.
09:10 AM 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
09:11 AM mozmck: http://linuxcnc.org/docs/html/examples/spindle.html
09:12 AM mozmck: https://forum.linuxcnc.org/21-axis/31786-motion-spindle-at-speed
09:13 AM Jin^eLD: thats the pin, thank you :)
09:13 AM mozmck: There is also a motion.feed-inhibit pin that might be useful if that does not do exactly what you need.
09:13 AM mozmck: you're welcome!
09:14 AM Jin^eLD: curious if that all will work out in the end :) my first component
09:23 AM cradek: mozmck: you're right about my assumptions - I would have to think about how fixed gears should work
09:23 AM cradek: gcode doesn't really match it very well, does it
09:23 AM cradek: and spindle override percentage doesn't match it very well either
09:24 AM Jin^eLD: people who have that mill and run it on the native philips controller had to prepare gcode to only send supported speeds
09:24 AM Jin^eLD: otherwise it would refuse the code
09:24 AM cradek: well that's one way to do it :-)
09:24 AM Jin^eLD: with LinuxCNC we of course were hoping to improve on that ;)
09:25 AM Jin^eLD: so I map any input to the closest supported gear/speed
09:26 AM 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.
09:27 AM mozmck: I think a higher spindle speed generally won't hurt though.
09:27 AM cradek: you mean like if using fpr? is this a lathe?
09:27 AM mozmck: Jin^eLD said "people who have that mill", so I think it's a mill?
09:28 AM cradek: ah
09:28 AM mozmck: I assume the same would be true of a lathe also though.
09:28 AM Jin^eLD: its a MAHO MH400E mill
09:28 AM Jin^eLD: my buddy asked me to lean to lower speeds
09:28 AM Jin^eLD: i.e. when something is right down the middle, I chose the lower gear
09:29 AM Jin^eLD: but that would be easy to tune I guess
09:29 AM mozmck: Huh, ok. You might mention that to him though - he should know if he is a machinist!
09:29 AM Jin^eLD: I will tell him
09:33 AM Jin^eLD: that spindle-at-speed pin - this is only for LinuxCNC right? or should it be connected to the machine too?
09:33 AM Jin^eLD: he tells me:
09:33 AM Jin^eLD: I can't provide an input to that pin, as there is no encoder on the
09:33 AM Jin^eLD: spindle. The closest thing on the MAHO is the Spindle _stopped.
09:33 AM 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?
09:35 AM 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.
09:35 AM Jin^eLD: got it
09:35 AM 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
09:35 AM Jin^eLD: so thats indeed what we need
09:35 AM cradek: yes
09:37 AM Jin^eLD: thanks guys :)
11:33 AM rene_dev_: thanks seb_kuzminsky :)
12:10 PM skunkworks: we do that on the K&T. 16 gears
12:10 PM skunkworks: we also make it so spindle override doesn't try to change gears...
12:13 PM Jin^eLD: skunkworks: what speed do you report back after quantizing? the real one, right?
12:13 PM Jin^eLD: i.e. its not a problem if someone requested 85 but we were only able to set 80 and report back 80?
12:25 PM skunkworks: the real one
12:25 PM skunkworks: I have a vfd + gears so I can run any speed
12:26 PM skunkworks: (don't laugh)
12:26 PM skunkworks: http://electronicsam.com/images/KandT/conversion/testing/config/gearshift16.comp
12:27 PM 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
12:27 PM Jin^eLD: :)
12:29 PM Jin^eLD: either the tabs are messed up in the browser or you have an unorthodox coding style =)
12:29 PM Jin^eLD: I'm surprised how short it is, the MAHO seems a lot more complicated
12:30 PM Jin^eLD: I'm already at over 1100 lines of code
12:44 PM skunkworks: it is unorthadox coding style
12:45 PM Jin^eLD: :)
12:45 PM skunkworks: it has been pretty solid. I cannot think of any issues
12:45 PM 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
12:45 PM Jin^eLD: a loogical pain
12:45 PM Jin^eLD: *logical
12:46 PM 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
12:46 PM skunkworks: https://www.youtube.com/watch?v=22dWg3GbywE
12:46 PM 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
12:46 PM Jin^eLD: sorry can't watch, I am on a traffic limited mobile connection :P
12:47 PM skunkworks: 4 shift rails - it senses the rail pressure to see if they have enguages..
12:48 PM skunkworks: engaged
12:48 PM skunkworks: (slowly rotates counter clockwise to shift)
12:49 PM skunkworks: seems to me someone has already done it.. for a maho
12:50 PM 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
12:50 PM skunkworks: sorry video https://www.youtube.com/watch?v=kmLmR8ckn2s
12:50 PM Jin^eLD: do you have a photo? I really can't watch videos here, traffic :P
12:50 PM Jin^eLD: we have a few pictures here: https://github.com/jin-eld/mh400e-linuxcnc/wiki/MH400E-Gearbox--Description and also two video links which I also did not have to chance to watch so far
12:51 PM Jin^eLD: there was a czech student who did a component for the MH500 I think, but thats the vfd version
12:51 PM 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
12:52 PM Jin^eLD: aehm, simiular to the MH400 I mean
12:52 PM Jin^eLD: doh, my typing..
12:53 PM seb_kuzminsky: rene_dev_: welcome aboard! :-)
02:14 PM Jin^eLD: one more question about spindle_at_Speed - when would be the best time to set it to false again?
02:14 PM Jin^eLD: easiest of course, before starting a gearshift, but I am not sure if thats not too late, forum says:
02:14 PM 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.
02:15 PM Jin^eLD: "unless a spindle speed change or start is commanded" - so setting it false right before a gearchange is too late
02:15 PM Jin^eLD: ?
03:02 PM 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.
03:03 PM Jin^eLD: I did not look at spindle-at-zero yet to ehonest
03:03 PM Jin^eLD: but I assume you mention it for a reason? I will read up on it
03:05 PM Jin^eLD: but my original question still stands, so any input on that would be helpful :)
03:08 PM Jin^eLD: where does spindle-at-zero come rom, I do not see it in the motion docs?
03:08 PM Jin^eLD: http://www.linuxcnc.org/docs/html/man/man9/motion.9.html
03:10 PM 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.)
03:11 PM KimK: Spindle-at-zero is an output that comes from the spindle drive usually, or maybe a stand-alone detector box of some kind.
03:15 PM 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.
03:16 PM Jin^eLD: aha, interesting
03:17 PM 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)
03:18 PM Jin^eLD: if our spindle-at-zero value is indeed zero - does it make sense to provide that pin? probably not?
03:18 PM KimK: OK, so you have a gearbox of the "stop and then activate spindle jogger (oscillator)" tyep
03:19 PM KimK: s/tyep/type/
03:19 PM Jin^eLD: yes, only that I have no oscillator but have to actually code it :)
03:19 PM KimK: OK.
03:19 PM Jin^eLD: I have two pins for twitch cw/twitch ccw and have to alternate myself
03:19 PM Jin^eLD: but I start only once the spindloe is stopped
03:20 PM Jin^eLD: the machine provides such a pin so I can check
03:20 PM KimK: You may want to include that timer I mentioned. Start jogging after stop indicated plus 300ms or some such.
03:22 PM Jin^eLD: ok wait, the jogging oscilator is a LinuxCNC thing?
03:22 PM Jin^eLD: I may have misunderstood you
03:22 PM Jin^eLD: I thought you were thinking the machine provided such an oscillator
03:23 PM 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.
03:24 PM KimK: Do you have a machine manual and schematics?
03:24 PM Jin^eLD: yes, my friend - thats who owns the machine and whom I am helping on the software side, got schematics from MAHO
03:25 PM KimK: Excellent. Then you can look at the spindle drive control I/O and see if there's anything unusual there.
03:25 PM Jin^eLD: he mostly came up with a "spec" on what the machine eppects
03:25 PM Jin^eLD: and told me which pins I should use and what they do
03:26 PM Jin^eLD: and for twitching, he told me the two pins that I am supposed to use
03:26 PM Jin^eLD: so I guess tahts fine
03:26 PM KimK: These are all pins on the original Maho spindle drive?
03:26 PM Jin^eLD: what I am not yet fully clear about is when to de-energize spindle-at-speed
03:27 PM Jin^eLD: thats how I understood it
03:27 PM KimK: You observe spindle-at-speed, it's an output from the spindle drive (or a black box).
03:28 PM Jin^eLD: well, yes, but the reason for my question was this line from the forum:
03:28 PM 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
03:28 PM KimK: You may not get spindle-at-speed during jogging though, consult yoour drive manual.
03:29 PM KimK: s/yoour/your/
03:29 PM Jin^eLD: so I need to tell LinuxCNC when I am ready with my gearshift
03:29 PM Jin^eLD: that I understand, but then later
03:29 PM Jin^eLD: I need to reset the pin back to false
03:29 PM Jin^eLD: and I am not sure when the best point for that would be, considering the line from the forums
03:32 PM 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?
03:34 PM Jin^eLD: OK, but the above describes when to set that pin to true, or am I misunderstanding?
03:35 PM 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
03:35 PM Jin^eLD: right?
03:35 PM Jin^eLD: and now - when do I set it back to flase?
03:35 PM 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.
03:35 PM Jin^eLD: just leave it high for some small amount of time and then reset it?
03:36 PM KimK: All this should happen automatically via your setup, HAL, ClassicLadder, external devices, whatever.
03:37 PM KimK: I guess your component in this case?
03:37 PM Jin^eLD: yes, sorry if I was not clear :)
03:37 PM Jin^eLD: by asking "when do I set it back to false" I meant, when do I decide to do that in the component
03:38 PM Jin^eLD: assuming that I did the steps above and set it true to signal I am ready
03:38 PM Jin^eLD: just keep it true for dunno, 500ms? 1s? and then automatically set it back to false?
03:38 PM 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.
03:39 PM Jin^eLD: uhm...?
03:39 PM KimK: Unless you *do* care because you're taking over manually for some reason (jogging?).
03:40 PM 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?
03:41 PM 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
03:42 PM cradek: it should be true when the spindle is turning at the specified speed, and false otherwise
03:42 PM Jin^eLD: cradek: i.e. if (current_speed == spindle_speed_in_abs) then spindle_at_speed = true; ?
03:43 PM cradek: so you should set it false when something changes that makes it so the spindle is no longer turning at the requested speed
03:43 PM Jin^eLD: ok, I think now I got it
03:43 PM cradek: I don't know why you'd use timers etc for this
03:43 PM Jin^eLD: I misunderstood how it works, now that you explained it again from this angle, I understand
03:43 PM cradek: cool
03:44 PM KimK: timers for "smoothness" because sometimes the stopped indication comes in below, say, 50 RPM, but it'
03:44 PM KimK: oops
03:45 PM 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).
03:46 PM 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
03:46 PM KimK: but the timer is just a delay from the actual signal, not a substitute for the actual signal
03:46 PM seb_kuzminsky: http://linuxcnc.org/docs/devel/html/man/man9/comp.9.html
03:47 PM cradek: seb_kuzminsky: his machine has N fixed-speed gearings
03:47 PM seb_kuzminsky: oh, right
03:52 PM KimK: Jin^eLD: Have we got you totally confused now?
03:53 PM Jin^eLD: :)
03:53 PM Jin^eLD: no,. I think cradeks final explanation was fine
03:53 PM 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
03:54 PM Jin^eLD: and spindle control is currently outside of the comp
03:54 PM Jin^eLD: I only have a pin that tells me if it stopped
03:54 PM Jin^eLD: I already wrote my friend to check this
03:54 PM Jin^eLD: some of you may know him from the forum, it's rotarySMP/Mark whom I am helping
04:06 PM 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.
04:31 PM JT-Shop: I think you need to do a pull request
04:31 PM 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
04:32 PM JT-Shop: did you change the .gitignore file so git can see the changes?
04:32 PM Joral: JT-Shop nope, new to git so I didn't know to change that lol
04:33 PM JT-Shop: yea anything in .gitignore is ignored by git, I like to use git gui
04:33 PM Jin^eLD: you can commit files in .gitignore by using -f (force)
04:33 PM seb_kuzminsky: Joral: debian/control is generated from debian/control.* by debian/configure
04:33 PM seb_kuzminsky: debian/control itself is not in our git
04:34 PM seb_kuzminsky: that's why it's not showing the change you made to it
04:34 PM Joral: seb_kuzminsky, gotcha, so how would we edit to show that the new package names still meet the dependencies?
04:35 PM * JT-Shop is glad seb chimed in it was getting over my head
04:36 PM 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
04:36 PM 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
04:36 PM seb_kuzminsky: some of the stuff is in debian/configure too, so you might have to change things in there
04:36 PM seb_kuzminsky: it's got all the distro-specific stuff
04:37 PM seb_kuzminsky: then here are the docs for how to get the changes into mainline: http://linuxcnc.org/docs/devel/html/code/contributing-to-linuxcnc.html
04:38 PM 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
04:39 PM Joral: ok, i will work on that
04:39 PM seb_kuzminsky: cool!
04:40 PM seb_kuzminsky: and feel free to ask more detailed questions here, someone will help out
04:42 PM 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
04:42 PM seb_kuzminsky: i think lowlatency is the normal kernel.org kernel, with the config tuned to minimize latency
04:43 PM seb_kuzminsky: the rt kernel is the kernel.org kernel *with* the rt-preempt patches, then configured to minimize latency
04:43 PM seb_kuzminsky: so the rt kernel will have *much* better latency than the lowlatency kernel
04:43 PM seb_kuzminsky: the lowlatency kernel is not what linuxcnc would consider a realtime kernel
04:44 PM Joral: ok, different question here then, will the linuxcnc build fail without a rt kernel?
04:44 PM seb_kuzminsky: it depends on how you configure linuxcnc
04:44 PM Joral: not building sim but full linuxcnc
04:44 PM seb_kuzminsky: in src/configure, if you say --with-realtime=uspace, it'll build on any kernel
04:44 PM 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.
04:45 PM Joral: ah, the uspace doesn't check the kernel
04:45 PM jepler: see detect_preempt_rt
04:45 PM seb_kuzminsky: a wild jepler appears!
04:45 PM jepler: (uspace will also try to run on rtai and xenomai depending on compile-time options)
04:45 PM seb_kuzminsky: see Joral , talking about uspace brings him out of hiding
04:45 PM jepler: (but that's just a curiosity and I don't recommend using it)
04:46 PM Joral: thats how I got it to build on lowlatency then i was using uspace with xenomai
04:47 PM 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.
04:50 PM 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.
04:52 PM 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
04:52 PM seb_kuzminsky: i wonder if the debian rt kernel would install on ubuntu?
04:52 PM Joral: seb_kuzminsky, the kernel is part of the system setup and wouldn't be part of the ebuild.
04:53 PM Joral: that was my next question, is there a ppa for the kernel to have it as a matched set?
04:53 PM seb_kuzminsky: right, it's in sys-kernel, and built by genkernel or by hand, as i understand it
04:53 PM seb_kuzminsky: we (linuxcnc) supply an rtai kernel for debian wheezy, from our repo
04:53 PM jepler: with uspace & preempt rt you're not tied to a single kernel. there are no kernel modules or other dependencies on kernel ABI.
04:54 PM 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...
04:55 PM jepler: looks like our wiki has some stuff (maybe from 2017?) about an ebuild of linuxcnc (it says to build your own kernel though)
04:56 PM 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.
04:57 PM seb_kuzminsky: yeah :-/
04:57 PM seb_kuzminsky: dont tell anyone, but i run stretch/rt-preempt on all my machines
04:57 PM jepler: yeah we are too timid to properly announce it, but that's the only thing you should run
04:58 PM seb_kuzminsky: http://linuxcnc.org/testing-stretch-rtpreempt/
04:58 PM 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
04:59 PM Joral: so silly question then, what is the new version of debian that ubuntu 18.04 is built on?
05:00 PM seb_kuzminsky: no idea
05:00 PM seb_kuzminsky: i stopped paying attention to ubuntu back in the 12.04 days
05:00 PM seb_kuzminsky: pure debian for me please
05:03 PM jepler: the internet tells me it's based on "buster / sid". buster was/is "testing" I think. sid is sid.
05:03 PM jepler: and that the file /etc/debian_version will spill the details for sure
05:04 PM seb_kuzminsky: yeah, buster is stretch+1
05:05 PM jepler: huh xenomai is working on ipipe-x86 for 4.14, so they're not totally done.
05:05 PM jepler: the branch is called "wip/4.14" so don't get your hopes too high
05:08 PM Jin^eLD is now known as Jin|away
05:08 PM Jin|away: thanks for the help, nite!
05:10 PM 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?
05:10 PM seb_kuzminsky: yeah, 9 is stretch, .5 is the current "patch level" or whatever they call it
05:11 PM Joral: so stretch is what I want?
05:12 PM seb_kuzminsky: yes
05:12 PM seb_kuzminsky: you can install from debian.org's installer iso, or from the one i linked above that is preconfigured for linuxcnc
05:13 PM Joral: missed the link lol, thanks
07:49 PM robotustra: good night
07:49 PM robotustra: have a question about linuxcncrsh
07:50 PM robotustra: actually more than one
07:51 PM robotustra: 1) http://linuxcnc.org/docs/html/man/man1/linuxcncrsh.1.html the example at the bottom of the page is not correct
07:51 PM robotustra: it's impossible to make "set mode manual" before "set estop off"
07:53 PM robotustra: 2) what is the right sequence of homing?
07:54 PM robotustra: when I do home x,y and then Z -I get an error message about "cannot home while shared home switch is closed"
07:54 PM robotustra: but if I home z,x,y everything is ok.
07:54 PM robotustra: is it bug of feature?
07:56 PM 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?
08:07 PM robotustra: I got the answer to quesion 3 myself
09:38 PM 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.