Back
[03:20:19] <ikcalB> zlog
[04:13:40] <ikcalB> compiled the 3.16.7 overnight, including rtai 4.1. unfortunately that kernel is not really realtime. cyclictest -n -N -p99 yields a maximum of approx. 500µs (3.4.9-rtai is under 200µs). not yet tested with hal
[07:04:28] <KGB-linuxcnc> 03John Thornton 052.7 24cab53 06linuxcnc 10(12 files) Docs: shorten application names and update hover over hints. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=24cab53
[07:04:28] <KGB-linuxcnc> 03John Thornton 052.7 0b758a5 06linuxcnc 10debian/extras/linuxcnc-doc-fr.files 10debian/extras/linuxcnc.files Docs: update the menus for french. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b758a5
[07:04:28] <KGB-linuxcnc> 03John Thornton 052.7 1d543b0 06linuxcnc 10docs/src/gcode/coordinates.txt 10docs/src/gcode/g-code.txt Docs: update and clean up some markups. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1d543b0
[07:32:44] <KGB-linuxcnc> 03John Thornton 052.7 7b7e1c9 06linuxcnc 10docs/src/gcode/tool-compensation.txt Docs: clean up and remove trailing spaces * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7b7e1c9
[07:44:45] <jepler> failed after 645 tests under strace
[07:49:00] <jepler> t.10918:write(2, "hm2_test: loading HostMot2 test "..., 59) = 59
[07:49:00] <jepler> t.10918:write(2, "hm2/hm2_test.0: invalid IDROM Po"..., 95) = 95
[07:49:01] <jepler> t.10918:write(2, "hm2_test.0: hm2_test fails HM2 r"..., 44) = 44
[07:49:01] <jepler> t.10918:write(2, "hm2_test: rtapi_app_main: Input/"..., 50) = 50
[07:49:37] <jepler> Note: Using POSIX non-realtime
[07:49:37] <jepler> hm2_test: loading HostMot2 test driver with test pattern 4
[07:49:37] <jepler> Waiting for component 'hm2_test' to become ready.hm2_test.0: hm2_test fails HM2 registration
[07:49:50] <jepler> but in this run, halrun-stderr doesn't have the second message
[07:51:45] <jepler> on the halcmd side,
[07:51:45] <jepler> write(2, "Waiting for component 'hm2_test'"..., 49) = 49
[07:51:46] <jepler> nanosleep({0, 10000000}, NULL) = ? ERESTART_RESTARTBLOCK (To be restarted)
[07:51:49] <jepler> --- SIGCHLD (Child exited) @ 0 (0) ---
[07:51:51] <jepler> restart_syscall(<... resuming interrupted call ...>) = 0
[07:51:54] <jepler> wait4(10924, [{WIFEXITED(s) && WEXITSTATUS(s) == 251}], WNOHANG, NULL) = 10924
[07:53:08] <jepler> so no write()s on stderr failed
[07:54:07] <jepler> no reopening of stderr that would explain why they stop sharing an offset
[07:54:38] <jepler> no lseek(2)
[07:58:36] <jepler> and if they did *not* share an offset, then the missing message in this run would not be *totally* hidden by the 'waiting for component' message, since the missing message is 95 bytes and the message from halcmd is 49 bytes
[07:58:43] <jepler> Running test: .
[07:58:44] <jepler> Write failed: Broken pipe
[07:58:44] <jepler> Runtest: 1 tests run, 1 successful, 0 failed + 0 expected
[07:58:44] <jepler> iteration 37
[07:58:47] <jepler> huh
[08:02:26] <KGB-linuxcnc> 03John Thornton 052.7 99e68e5 06linuxcnc 10docs/src/gui/tooledit.txt Docs: fix section title * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=99e68e5
[08:10:08] <jepler> with the time before the "waiting" message is printed reduced, it failed after just 68 trials
[08:11:21] <jepler> ikcalB: does cyclictest work with rtai realtime? we always have sai to use the rtai kern/latency test for a first check of RT performance of RTAI
[08:11:43] <jepler> 500us and 200us are both uselessly bad latencies if you want hardware step generation
[08:12:04] <jepler> s/sai/said/
[08:12:07] <jepler> afk
[08:31:24] <ikcalB> jepler: cyclictest is obviously not using rtai (just thought that might be related) and got exactely the answer i was looking for: the tool to use for testing. (that one makes the pc freeze, unfortunately- going to look into this)
[08:37:53] <jepler> ikcalB: afaik RTAI doesn't improve realtime performance of software that doesn't use RTAI's APIs
[08:42:20] <ikcalB> jepler: actually it does, quite a lot. (as comparing that test to my stock 3.16 shows) - ofc i should not have assumed that to scale linearly to rtai performance.
[08:42:39] <jepler> that's interesting! I stand corrected.
[08:42:46] <ikcalB> jepler: yet i'm not able to run that kernel/latency/run, which makes my pc freeze
[08:43:14] <ikcalB> have you encountered something like that / any ideas?
[08:44:14] <jepler> if you are in text mode when the kernel crashes you have a slightly better chance of seeing a kernel error onscreen
[08:46:21] <jepler> running the kernel under test in qemu, you of course won't get good realtime performance but you can debug the kernel. this looks like it's reasonbly current information about doing that:
http://wiki.osdev.org/Kernel_Debugging#Use_gdb_with_Qemu
[08:46:30] <jepler> I haven't ever done that myself
[08:48:10] <ikcalB> going to dig into that, good point!
[08:49:01] <ikcalB> was just trying to run in text mode (had to spawn the vttys manually) - actually the system does _not_ freeze, just X (so it seems)
[08:51:18] <ikcalB> jepler: that test does not spit out anything until cancelled, then the min/max latencies are stuck on some years
[08:51:39] <jepler> that happens if the realtime portion never begins executing
[08:54:08] <ikcalB> hm. dmesg does not show errors, just usual loading / unloading infos. - though the testsuite is outdated, /proc/rtai/latency_calibrate is now kern_latency_calibrate. changing that and recompiling
[08:56:32] <seb_kuzminsky> jepler: curiouser and curiouser
[08:57:06] <seb_kuzminsky> my test here passed 19,000 test runs with no failures
[08:57:24] <seb_kuzminsky> that's on jessie-amd64 with 'make setuid', not sure if that's relevant
[08:57:43] <seb_kuzminsky> it must be a jessie thing, this test has never failed (as far as i remember) on any of the other slaves
[10:00:48] <Roguish> JT-Shop: you were wondering about servo power sizing? do not forget about inertia match in the motors also. anyway, find a good 'motor sizing software' and run it. check a few of the major motor/drive manufacturers for their freeware. most will give it away. there may even be some 'online' stuff now. of course, this is if you are looking for really good performance.
[10:04:04] <JT-Shop> I need speed but not accuracy this is a nailing platform so +-.050 is fantastic
[10:04:57] <Roguish> OK, that's important. the speed / accel is what really defines sizing.
[10:04:59] <Roguish> http://www.orientalmotor.com/support/motor-sizing.html
[10:05:43] <Roguish> http://www.motioncontroltips.com/2012/08/24/tips-for-sizing-a-servo-motor/
[10:06:03] <JT-Shop> thanks for the links
[10:06:36] <Roguish> http://ab.rockwellautomation.com/Motion-Control/Motion-Analyzer-Software
[10:06:56] <Roguish> Kollmorgan used to have the best (in my opinion) not sure now.
[10:07:16] <JT-Shop> thanks, I'll check them out when I get back, have to run now
[10:07:30] <Roguish> the inertial matching is what is usually missed by designers.
[10:07:52] <Roguish> ok. i'm off now to. got to assemble a machine.
[10:07:54] <Roguish> latere.
[10:08:01] <Roguish> ttfn
[10:50:18] <CaptHindsight> does anyone now what version or RTAI ikcalB is trying to get working on 3.16 kernels?
[10:50:25] <CaptHindsight> or/of
[10:51:56] <CaptHindsight> oh farther back in the scrollback rtai 4.1, he's in for lots of wasted time
[10:53:21] <CaptHindsight> he could just use memleaks RTAI for 3.16
https://github.com/NTULINUX/RTAI
[10:55:02] <CaptHindsight> is there a way to leave a note here for ikcalB?
[10:55:44] <CaptHindsight> RTAI 4.1 is not going to work with Linuxcnc
[11:07:52] <jepler> CaptHindsight: I think /msg memoserv help will put you on the right track to leave a note for someone who is not around
[11:08:08] <jepler> though that may only work for registered users, and it appears he may not be one.
[11:08:45] <jepler> /msg MemoServ SEND nhandler Please contact me when you get this message.
[11:12:50] <CaptHindsight> it's never easy
[11:13:46] <CaptHindsight> just trying to save him some time
[11:19:31] <jepler> huh there are a wealth of sub-$200 laser engravers that run a GRBL-based control
[11:19:36] <jepler> I am sure they are terrible
[11:19:42] <jepler> how well is a 300mW blue laser going to engrave anything?
[11:21:31] <pcw_home> ~5 W blue diode laser migh be OK if slow
[11:25:48] <CaptHindsight> they must be selling
[11:26:44] <CaptHindsight> common sense has been out the window, those glue gun printers also sold like hotcakes
[11:26:46] <jepler> looks like they typically have a socketed mcu similar to arduino mini and 2 unipolar motor drivers similar to "easy driver", so it would be pretty easy to adapt to mesa just by popping the arduino off
[11:26:59] <jepler> CaptHindsight: yeah I have a non-working glue gun printer myself
[11:27:27] <jepler> seems sensible to add a poorly-working laser engraver to the pile
[11:27:46] <CaptHindsight> I was looking at small laser engravers recently myself
[11:28:07] <pcw_home> 1W on a tormach (linuxcnc)
[11:28:09] <pcw_home> https://www.youtube.com/watch?v=4v4gqVnqJU4
[11:28:15] <CaptHindsight> I was shocked as well by all the <1W versions
[11:28:47] <jepler> and I assume this other chip is the LED driver, maybe just a ULN array or something
[11:31:39] <jepler> haha it has a sticker on it which proclaims that it is "ROSH" (sic, not ROHS). I assume a closer look at the "CE" and "FCC" logos would reveal they are not genuine either
[11:32:07] <cradek> wow
[11:35:17] <skunkworks> wekk - that works
[11:35:19] <skunkworks> well
[11:38:35] <jepler> skunkworks: what's up?
[11:38:59] <jepler> > 3.Please pause 3-5 minutes after engraving continuously about 30 minutes,long time engraving will damage the laser module,kindly hope your understanding.
[11:39:33] <skunkworks> Sorry - commented on the 1w laser.
[11:39:46] <skunkworks> wow
[11:40:28] <skunkworks> I was going to setup precise on the K&T so it was similar to 10.04 but I think I am just going to swith to wheezy
[11:49:29] <jepler> > I work with old German Zeiss ILA-120A argon ion laser. Power consumption is 16kW (yes - 16000W or 16∗103W) and useful output is 3W. Now that's poor efficiency.
[11:50:32] <skunkworks> well - to get some of the odd wavelenghts... We have a co2 laser 1kw. it runs on 220 3 phase
[11:51:01] <skunkworks> I don't know what the ratio is - but it is bad also
[11:51:09] <skunkworks> (just not that bad)
[11:53:37] <pcw_home> I think CO2 lasers are about 10% efficient
[11:53:51] <pcw_home> Diode lasers up to 50% or so
[11:55:39] <ssi> yea 10% is about right
[11:56:33] <ssi> also the power output of the laser is only part of the story
[11:57:07] <ssi> energy density is more important, which is determined by focused spot size, in units of kw/mm^2
[11:57:46] <ssi> power density I guess to be pedantic
[11:57:53] <jepler> I imagine these sub-$200 engravers are using laser focus via wishful thinking
[11:57:58] <pcw_home> yeah and pulsed lasers can get by with lower average power
[11:58:34] <ssi> jepler: :D
[11:58:53] <ssi> pcw_home: that's true with CO2, not sure if it's true universally
[11:59:11] <pcw_home> I think its universally true
[11:59:29] <ssi> it works with CO2 because there's an instantaneous peak of power when the tube is fired, tapering off to the nominal power output
[11:59:34] <ssi> the tube is basically a resonant tank
[11:59:47] <ssi> well it's exactly a resonant tank, that's why it's a laser :P
[12:00:06] <ssi> but I'm not sure diodes behave that way
[12:00:28] <pcw_home> A 1 w laser is not impressive a 10 KW peak laser with a .01 duty cycle will etch copper
[12:00:30] <pcw_home>
[12:00:35] <CaptHindsight> jepler: just FYI, RTAI 4.1 is not going to work with 3.16 and Linuxcnc
[12:00:57] <pcw_home> .01% = 1W average
[12:00:58] <seb_kuzminsky> some issue with /proc?
[12:01:01] <CaptHindsight> thats why memleak spent ~1 year working on the other branch of RTAI
[12:01:05] <seb_kuzminsky> CaptHindsight: ^^^
[12:01:26] <seb_kuzminsky> is there some obstacle to updating linuxcnc to work with rtai 4.1?
[12:01:59] <CaptHindsight> several, that why he spent so much time rewriting it for you guys
[12:03:04] <jepler> > Pulsing the laser diode generates more average pump power for the same average electrical input power because of the characteristics of the laser diode - the output is essentially 0 until the lasing threshold is reached and increases linearly with current after that.
[12:03:08] <jepler> For a typical pump diode with a lasing threshold of 75 mA and a slope efficiency of 0.6 W/A, pulsing at 300 mA with a 50 percent duty cycle instead of a constant 150 mA will result in 50 percent more average pump power (three times the peak power) although the electrical input power will be very nearly identical since the voltage drop (around 2 V for a typical diode) doesn't vary much with current (
[12:03:14] <jepler> 150 mA * 2 V being equal to 300 mA * 2 V * 0.5). The actual output power will be about 135 mW peak (67.5 mW average) compared to the CW power of 45 mW.
[12:03:17] <jepler> http://www.repairfaq.org/sam/laserssl.htm
[12:03:29] <ssi> nice
[12:13:10] <CaptHindsight> seb_kuzminsky:
https://github.com/NTULINUX/RTAI is for Linuxcnc with kernels up to 3.16 and 3.18
[12:14:57] <jepler> I wonder why there are still no PRU development tools in the debian main archive
[12:15:29] <jepler> the pasm source in
https://github.com/modmaker/am335x_pru_package looks OK
[12:16:36] <jepler> .. in terms of license
[12:17:25] <jepler> I can't even spot any ITPs
[12:29:28] <CaptHindsight> seb_kuzminsky: memleak mentioned the problems are: maths, 64bit and Linuxcnc uses legacy i-pipe and the new RTAI has moved away from that, so memleak has been keeping the legacy i-pipe in his branch
[13:01:24] <seb_kuzminsky> ok thanks
[15:24:33] <cradek> it's stupid how debian does things after saying installation is complete
[15:24:46] <cradek> it says "finishing the installation" and then does time-consuming things
[16:48:02] <andypugh> Is this the time to merge JA into master and commit to be being in 2.8?
[16:52:12] <seb_kuzminsky> andypugh: ja should not be merged until lathes work again
[16:52:35] <andypugh> Ah, I didn’t know they were broken. That does seem like something of an issue
[16:52:51] <micges> seb_kuzminsky: what broken on lathes on ja?
[16:53:16] <andypugh> I am running an old JA on my mill, but the lathe is on 2.6 Wheezy
[16:53:21] <seb_kuzminsky> sam and cradek reported that non-consecutive joints dont work on ja
[16:53:49] <andypugh> JA Lathe joints shouldn’t need to be nonconsecutive.
[16:54:02] <andypugh> Joints 0 and 1 are axes X and Z?
[16:54:40] <seb_kuzminsky> x=0, y=1, z=2 on trivkins
[16:54:59] <seb_kuzminsky> so having joints 0 and 2 but not 1 apparently causes the problem
[16:55:23] <andypugh> Hmm, I wonder if gentrivkins works?
[16:55:35] <seb_kuzminsky> it's somewhat distressing that we don't have any tests of this kind of setup, so we didn't know about the problem until sam tried it on his xyzb machine
[16:55:54] <seb_kuzminsky> but, i've got a couple of nontrivkins machines that would love to have ja merged
[16:56:08] <micges_> gentrivkins should be used on lathes
[16:56:17] <seb_kuzminsky> as soon as it's ready, which is as soon as someone digs in and fixes it
[16:56:53] <andypugh> I keep maeaning to detrivialise my mill. It has a tilting head, and I want to have a W axis.
[16:59:10] <andypugh> Is it worth making trivkins identically equal to gentrivkins in JA? So configs that currently load trivkins actually get a gentrivkins which defaults to a trivkins?
[17:01:20] <micges> yeah it would be very usable
[17:05:45] <micges> andypugh: loadrt gentrivkins coordinates="XZ" will fix lathe problem on ja
[17:08:40] <skunkworks> cradek: you sneaked out an iso!.. I went to apt-get update/upgrade and nothing happened.
[17:14:49] <seb_kuzminsky> he's sneaky that way
[17:15:26] <seb_kuzminsky> micges: that's a good work-around, but it would be good if ja also handled non-consecutive joints correctly
[17:25:29] <micges> seb_kuzminsky: do you have any specifc case in mind besides lathes that it would be helpful?
[17:32:11] <micges> actually as I think about it, there shouldn't be any non-consecutive joints at all in ja by design
[17:35:36] <jepler> other cases that are currently non-consecutive include: xyuv foam cutters, xyzw mills, xyzac and xyzbc rotaries
[17:57:49] <andypugh> Those have non-consecutive Axes, they shouldn’t have non-consecutive joints. Non-consecutive joints just wastes memory and CPU
[18:01:07] <jepler> sorry, I was answering the wrong question then
[18:01:38] <jepler> I was talking about what kinds of configurations today have non-consecutive numbering because they have gaps in the XYZABCUVW sequence and are kinds we know exist
[18:13:40] <andypugh> Indeed, I suspect that the reported issue with lathes is a failue to fully enter into the spirit of JA
[18:35:37] <cpresser> concerning tests: why not use sim configurations for that?
[18:36:35] <cpresser> for my scara build, I am currently implementing all features of the real machine (end stops, homing, ...) also in sim. why not use such a setup to test mill/lathe/...?
[18:38:22] <andypugh> cpresser: Do you also have a Vismach?
[18:38:53] <andypugh> if you have a 3D model then making a Vismach version is pretty easy.
[18:39:42] <andypugh> Hmm… I might make a Vismach Holbrook lathe. I don’t think we have a pretty lathe sim
[18:40:01] <cpresser> andypugh: yes. there is already a vismach gui for scara in 2.7 :)
[18:40:52] <seb_kuzminsky> cpresser: by "test" i meant something automatic, like in our tests/ directory
[18:41:08] <seb_kuzminsky> something that can be verified mechanically, automatically, without a human having to do anything
[18:41:23] <cpresser> seb_kuzminsky: yes, i think one could do that with sim. it takes time, but works
[18:41:45] <cpresser> one could test if virtual switches are hit; or check the timing
[18:42:02] <cpresser> since the simulation is realtime, those tests arent that fast
[18:42:11] <seb_kuzminsky> there are a bunch of tests that set up simulated machines
[18:42:43] <seb_kuzminsky> for example tests/toolchanger/m61
[18:42:49] <seb_kuzminsky> i agree, it works well
[18:49:08] * cpresser will try to push some patches for scarakins and scara examples soon
[18:49:24] <cpresser> there are some minor but annoying problems
[19:04:11] <zeeshan> andypugh: is that file what handles the display in axis?
[19:05:10] <andypugh> zeeshan: You mean in the other channel?
[19:05:14] <zeeshan> yes
[19:05:20] <zeeshan> i thought you posted it accidently there :P
[19:06:12] <andypugh> No, cpresser asked the question over there…
[19:06:52] <Tom_itx> skunkworks, i have verified that: in MDI tab S 200 M3, switch to Manual Control pressing STOP works
[19:07:16] <Tom_itx> skunkworks, there is still something fishy about my pendant spindle button code
[19:07:36] <Tom_itx> once i push the spindle start/stop button things don't work properly in axis
[19:08:04] <cpresser> it sounded more like a user-question
[19:08:07] <Tom_itx> this happens when you set code aside and get back to it 6-9 mo later
[19:08:46] <Tom_itx> seb_kuzminsky, that spindle issue i mentioned seems to be in my hal file
[19:17:46] <Tom_itx> i remember having trouble figuring out the logic on this now...
[19:18:47] <Tom_itx> i wanted to be able to turn the spindle off in manual mode AND in auto mode but only if the program was paused
[19:19:04] <Tom_itx> ^^ with the pendant
[19:19:30] <andypugh> Tom_itx: LUT5 is your friend :-)
[19:19:48] <Tom_itx> i recall you telling me that before too
[19:20:04] <Tom_itx> i had already started the logic on it so i wanted to try it
[19:20:28] <Tom_itx> and now i remember i hadn't quite finished it
[19:22:16] <andypugh> If you are using more than 3 inputs into your logic then LUT5 is always much simpler.
[19:23:04] <Tom_itx> i recall there being one state i couldn't figure out
[19:23:23] <Tom_itx> i can't recall which one it was now but i'll figure it out
[19:23:40] <andypugh> Here is a link to a google sheet to work out the LUT5 parameter:
https://docs.google.com/spreadsheets/d/1_VlL39jUOPpS8Tt9mpRK-eaSTS6C6PHBDoE3JitvLzs/edit#gid=0
[19:25:00] <Tom_itx> i think i even saved that but that was 2 MB and a couple hdd ago
[19:25:10] <Tom_itx> no tellin where it went
[20:37:12] <Tom_itx> ok i think the spindle is working normally now
[20:37:33] <Tom_itx> i had to add some logic for mdi mode for the pendant
[20:57:08] <skunkworks> lut5
[20:57:09] <skunkworks> ?
[20:57:11] <skunkworks> :)
[21:04:50] <Tom_itx> nope
[21:09:25] <Tom_itx> ok, apparently you can't turn the spindle on in auto mode with the program paused
[21:09:33] <Tom_itx> that generates an error message
[21:09:44] <Tom_itx> however you can turn it off
[21:09:50] <cradek> what
[21:10:12] <Tom_itx> unless my logic is all screwed up still
[21:10:25] <Tom_itx> but i've tested it fairly thorough
[21:11:02] <Tom_itx> i want to be able to turn the spindle on and off in manual, mdi and in auto mode but in auto mode only if the program is paused
[21:11:36] <Tom_itx> i can turn it off with the pendant in auto mode when it's paused but get an error when i try to turn it back on
[21:12:40] <Tom_itx> i need to double check the logic to be absolutely certain
[21:23:24] <Tom_itx> watching the logic in Hal Config it looks like it is all working except in the mode described above, toggle2nist doesn't toggle it's output when the input toggles
[21:29:04] <cradek> is it in a thread?
[21:29:32] <Tom_itx> yes, it works in all other modes
[21:29:40] <Tom_itx> MDI and Manual Control
[21:30:37] <Tom_itx> the state of toggle2nist.x.is-on doesn't seem to affect it's control
[21:34:09] <Tom_itx> yeah, in auto mode when the program is paused, toggle2nist doesn't toggle it's outputs
[21:34:27] <Tom_itx> it's input is toggling
[21:35:56] <Tom_itx> it's outputs are tied to halui.spindle.start / stop
[21:36:46] <jepler> there are no sample configs or tests which use toggle2nist, so it's possible there's some gross oversight in how it operates.
[21:38:54] <Tom_itx> seems to work as expected in manual modes
[21:38:56] <Tom_itx> and mdi
[21:39:36] <Tom_itx> the outputs pulse either the 'on' or 'off' pin depending on it's state
[21:39:56] <Tom_itx> in auto mode / paused they are in a steady state
[21:40:25] <Tom_itx> they will trigger once in a while but stay in that state once triggered instead of a pulse
[21:41:28] <Tom_itx> lut5 looks confusing to me
[21:42:02] <jepler> if your hal setup which involves toggle2nist works as desired in manual mode but not in auto mode, then problem is probably not toggle2nist which has no knowledge of whether the machine is in manual mode or auto mode.
[21:42:27] <Tom_itx> sounds reasonable
[21:42:54] <cradek> toggle2nist is a state machine that depends on the feedback is-on following your command
[21:43:18] <cradek> if your command is being ignored it will probably just keep patiently asserting it forever
[21:43:38] <cradek> and if you're getting an error from task, your command is being ignored
[21:46:49] <Tom_itx> maybe i should be getting my signal from motion.spindle.on instead of halui.spindle.is-on
[21:47:03] <jepler> doing this in a terminal in auto mode with program paused, the spindle will turn on
[21:47:06] <jepler> halcmd: setp halui.spindle.start 1
[21:47:08] <jepler> halcmd: setp halui.spindle.start 0
[21:47:11] <jepler> halcmd: setp halui.spindle.increase 1
[21:47:13] <jepler> halcmd: setp halui.spindle.increase 0
[21:47:53] <jepler> testing with master branch apparently
[21:48:33] <Tom_itx> i can see that should work
[21:48:54] <Tom_itx> so you pulse halui.spindle.start?
[21:49:22] <jepler> right, just doing it by hand to simplify things
[21:49:41] <jepler> I modified the sim/axis/lathe.ini config to load halui, and look at its spindle speed readout to know what happened
[21:49:42] <Tom_itx> yeah, toggle2nist.on is tied to it
[21:49:56] <Tom_itx> and toggle2nist.off is tied to halui.spinde.stop
[21:51:15] <jepler> I am not involving toggle2nist at all in my testing, because I am testing halui
[21:51:20] <Tom_itx> well, i can simplify my pendant code and live with it but i was hoping to get it to work in that state as well
[21:51:31] <Tom_itx> being -> auto mode program paused
[21:51:44] <Tom_itx> yeah i know
[21:52:13] <Tom_itx> i'm just trying to squeeze more functionality from the pendant pin
[21:52:19] <Tom_itx> i can live with it
[21:54:17] <Tom_itx> at least i have narrowed where the failure is i think
[21:54:35] <Tom_itx> i may look for another signal to use there instead of what i'm using
[21:56:08] <Tom_itx> i get a following error once in a while but other than that so far 2.7.0 is working pretty solid