Back
[07:01:32] <jepler> seb_kuzm1nsky: wheezy-rtpreempt-amd64 disconnected from buildbot again
[07:29:05] <jepler> sigh ubuntu has still not fixed a raft of php bugs, some of which are documented as remotely exploitable by php maintainers.
https://bugs.php.net/bug.php?id=72434 https://security-tracker.debian.org/tracker/CVE-2016-5773 https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5773.html
[07:30:11] <jepler> php calls it: "critical use after free vulnerability" "remote code execution". ubuntu calls it "priority medium" and hasn't fixed it in any security update
[07:31:03] <jepler> sigh if only I'd taken an extra week setting up the forum by hand on debian instead of using a one-click installer based on ubuntu
[07:36:53] <skunkworks> It will be fine. Nobody would want to hack linuxcnc forum anyway ;)
[07:37:44] <archivist> you think that, I get a number of attacks into my little outpost on the net
[07:38:34] <skunkworks> yah - I have one machine that I ssh into - it gets hit often trying to guess username/passowrd.
[07:40:04] <archivist> when I here the disk activity rise I check what is going on, fiddle with a relevant cockup and set a 404 or F off message
[07:40:06] <skunkworks> I really should switch it to use public/private keys instead of username/password
[07:41:23] <archivist> a couple of weeks ago someone was attempting an attack on the linuxcnc meeting page
[08:11:11] <JT-Plasma_> seb_kuzm1nsky, running .configure I get an error configure: error: boost::python is required to build LinuxCNC
[08:11:30] <JT-Plasma_> I can't seem to find the correct library
[08:12:29] <skunkworks> I booted up one of the printer port machines here - updated it to 2.7.5 and not having issues with pause or escape. sorry.
[08:13:08] <JT-Plasma_> http://paste.ubuntu.com/20173565/
[08:13:27] <JT-Plasma_> bbl
[08:16:14] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15samcoinc commented on issue #68: Does tolerance effect the blending on spindle synced motion? (g64Px.xxx).. If you wanted the path to follow better (or try to) could you just specify it? 02
https://github.com/LinuxCNC/linuxcnc/issues/68#issuecomment-233938914
[08:21:00] * skunkworks too lazy test right now...
[08:36:57] <skunkworks> or type coherent sentences..
[08:41:38] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/151118
[08:46:07] <cradek> ding ding
[09:22:05] <CaptHindsight> jepler: going back to the Rpi3 discussion a few days ago, even though the Rpi3 GPU only supports OpenGL-ES 1.1/2.0 and OpenVG 1. vs glx and OpenGL 1.x I believe the glx gets software rendered ...
[09:22:50] <CaptHindsight> and since the Rpi3 is fast enough AXIS ends up running smoothly @ HD res
[09:23:20] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek commented on issue #68: I think synced motion along a complex path is extremely rare, but it has been used. The longer lead-in you mention is more important, but I think it would be fine; I have not ever heard someone say they could not manage a lead-in because of limited space. I guess the nature of threads is that one end is exposed... 02
https://github.com/LinuxCNC/linuxcnc/issues/68#issuecomment-233956383
[09:23:24] <jepler> CaptHindsight: good info, thanks
[09:23:44] <CaptHindsight> same is true with the Orange Pi, it has so many arm cores that software rendering is smooth and fast enough
[09:27:06] <CaptHindsight> but getting Linuxcnc to use OpenGL-ES 1.1/2.0 and OpenVG 1 would be nice since then these <$40 ARM boards would have enough CPU left to handle Linuxcnc plus machine vision or some other heavy background app
[09:27:36] <jepler> skunkworks: I know you were being tongue in cheek, but the forum has about 30,000 failed ssh login attempts since 2016-07-17
[09:27:54] <jepler> to my surprise there aren't rafts of obvious php/sql sploit attempts in the httpd access.log
[09:28:24] <CaptHindsight> but the gotcha with ARM boards with Mali GPU's is that they won't release driver source or some kind of tool to be able to compile your own kernels
[09:28:32] <skunkworks> the internet is a scary place!
[09:28:40] <CaptHindsight> the Rpi3 has an open driver
[09:31:16] <jepler> looks like maybe under 300 obvious php/sql sploit attempts in the same time frame
[09:34:05] <mozmck> maybe the php exploits are only valid under certain uncommon conditions or setups?
[09:34:29] <mozmck> (the ones ubuntu calls medium priority)
[09:37:12] <skunkworks> wow - closing chrome - now my laptop goes to lock screen.
[09:38:06] <seb_kuzm1nsky> JT-Plasma_: look here for how to satisfy build dependencies:
http://linuxcnc.org/docs/devel/html/code/building-linuxcnc.html#Satisfying-Build-Dependencies
[09:39:15] <seb_kuzm1nsky> jepler: bummer, i was hoping that 4.1.6 kernel would fix the hangs
[09:40:29] <seb_kuzminsky> jepler: the console has new errors on it:
http://highlab.com/~seb/linuxcnc/Screenshot_jessie-rtpreempt-amd64_2016-07-20_08:12:42.png
[09:40:58] <seb_kuzminsky> acpi shutdown worked
[09:41:03] * seb_kuzminsky sighs
[09:41:51] <seb_kuzminsky> oh wait, no that was jessie-rtpreempt-amd64 i just rebooted
[09:41:55] <seb_kuzminsky> durr
[09:42:01] <seb_kuzminsky> wheezy was locked up tight
[09:42:29] <skunkworks> I was rsyncing between a few servers here at work and almost rebooted the main server by mistake
[09:46:09] <jepler> skunkworks: I recommend installing "molly-guard" and setting ALWAYS_QUERY_HOSTNAME=true in /etc/molly-guard/rc
[09:47:27] <mozmck> Ah, I found the descriptions of the ubuntu security priorities
https://people.canonical.com/~ubuntu-security/cve/priority.html
[09:48:34] <skunkworks> jepler, oh - cool
[09:50:54] <jepler> mozmck: apparently "100% remotely exploitable but in a package that is not installed by default" would never be higher than "medium"
[09:51:51] <mozmck> hmm, that could be
[09:52:28] <mozmck> It does say updates should be made soon. Now we just have to find a definition of "soon"
[09:52:46] <archivist> after it becomes EOL
[09:53:10] <jepler> # apt-cache show php5 | grep ^Supported
[09:53:10] <jepler> Supported: 5y
[09:53:23] <jepler> ubuntu's unpaid support is worth every cent
[09:53:48] <mozmck> Was it built with --enable-zip?
[09:54:20] <jepler> without checking, I'd bet that it is.
[09:54:21] <mozmck> I would assume so if they say a fix is needed.
[09:56:03] <jepler> there are actually at least 6 distinct recent CVEs in PHP that Debian has fixed and Ubuntu has not.
https://security-tracker.debian.org/tracker/DSA-3618-1
[10:04:34] <CaptHindsight> is anyone interested in getting together at Stuarts (Wichita) in October?
[10:04:43] <CaptHindsight> that thread keeps dying
[10:06:07] <mozmck> I'm interested, but yeah it seems like the thread does keep dying.
[10:08:53] <CaptHindsight> maybe next year
[10:16:22] <cradek> hm seems like my hal_parport change wouldn't cause all these tests to fail:
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4376/steps/runtests/logs/stdio
[10:16:58] <jepler> cradek: (without looking at the errors) no, it was one of seb's changes. we talked about it yesterday afternoon at 4ish central
[10:17:06] <cradek> oh!
[10:17:48] <cradek> I see it, thanks
[10:19:25] <cradek> still, I can see it built on all the platforms
[10:23:18] <seb_kuzminsky> cradek: yeah that failure was mine, yesterday morning, i fixed it just after i noticed
[10:23:37] <cradek> yay, thanks
[10:23:49] <seb_kuzminsky> CaptHindsight: i really want to have a hackfest this year!
[10:23:56] <linuxcnc-build> build #518 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/518 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:24:02] <seb_kuzminsky> i'd come to Stuart's any time, pretty much
[10:24:35] <cradek> I'd go too, unless it conflicts with that work thing affecting jeff and me
[10:25:19] <seb_kuzminsky> cradek: what dates are unavailable for you?
[10:25:31] <seb_kuzminsky> i got the feeling stuart was pretty flexible on when he could host
[10:26:22] <seb_kuzminsky> he said: I want to reiterate the date is not set in stone (unless we want it to be).
[10:26:25] <skunkworks> cradek, cool! I didn't see the commit
[10:26:26] <seb_kuzminsky> I want to facilitate anyone's schedule so if we have conflicts let's change
[10:26:28] <seb_kuzminsky> the date to resolve them.
[10:27:29] <jepler> cradek: help me get this right, October 3-14 ?
[10:28:26] <cradek> yes that's what I came up with too
[10:28:38] <cradek> I think those two weeks are the ones that would give us trouble
[10:30:02] <CaptHindsight> Monday October 10 is Columbus Day
[10:30:19] <CaptHindsight> so an extra day off for some
[10:31:43] <seb_kuzminsky> I'm busy November 16-20, otherwise free
[10:32:12] <seb_kuzminsky> so, second half of october, beginning of november?
[10:33:08] <CaptHindsight> before the snows
[10:33:35] <CaptHindsight> last year we got several inches of snow before Thanksgiving
[10:33:49] <cradek> if it was up to the two of us, I bet the week after the 14th would be ideal
[10:34:11] <mozmck> As far as I know I don't have any conflicts any time in there.
[10:34:17] <CaptHindsight> lets ask Stuart
[10:34:43] <skunkworks> cradek, How do you envoke force_epp in the config string?
[10:34:47] <cradek> it's me screwing it up, I'll send an email
[10:34:58] <cradek> skunkworks: use mode epp instead of in/out/x
[10:35:08] <skunkworks> oh - ok
[10:35:17] <skunkworks> (I failed at reading the source..)
[10:35:18] <cradek> epp is just like out except it tries to enable epp
[10:35:37] <cradek> and I failed at writing docs
[10:35:42] <skunkworks> heh
[10:39:57] <cradek> I mailed that proposed change
[10:40:02] <cradek> hope it doesn't mess anyone else up
[11:10:35] <cradek> and stuart says "yeah whatevs"
[11:10:38] <cradek> whee
[11:39:53] <seb_kuzminsky> yaaay
[11:42:56] <cradek> hm the parport docs don't say how to have more than one parport
[11:43:27] <seb_kuzminsky> + If you need more than one parport, buy a 7i43.
[11:43:29] <cradek> (struggling to add the epp mode in a sane way)
[11:44:19] <cradek> https://files.growery.org/files/g11-44/051292441-Jon_Stewart_youre_not_helping.jpg
[11:44:45] <cradek> ooh there's also grumpycat saying the same thing
[11:44:51] <cradek> so hard to choose
[11:45:13] <seb_kuzminsky> :-)
[11:48:33] <cradek> ha, the "is this real life?" kid
[11:49:35] <seb_kuzminsky> oh yeah, david after the dentist. the video is even better
[11:50:17] <seb_kuzminsky> reminds me of high school
[11:51:51] <JT-Shop> seb_kuzminsky: thanks
[11:54:13] <seb_kuzminsky> JT-Shop: if this is the first time building on that machine, the build deps might be a big download
[11:55:07] <seb_kuzminsky> looks like the abort-debug branch finished building, so you could install the deb for it if you want
[11:55:45] <seb_kuzminsky> http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/binary-i386/linuxcnc_2.7.5~seb.2.7.abort.debug~5c4caa1_i386.deb
[11:55:48] <seb_kuzminsky> 5.6 MB
[11:55:51] <cradek> CaptHindsight: are you going to fest?
[11:56:48] <CaptHindsight> going to try
[11:56:57] <seb_kuzminsky> CaptHindsight: i'll bring my 3d printer, you can make fun of it ;-)
[11:57:07] <cradek> ha
[11:57:12] <CaptHindsight> if not the week then at least the weekend
[11:57:25] <CaptHindsight> I'll bring one as well :)
[11:57:45] <cradek> historically the weekend has more users, the week previous has more time for developers
[11:58:19] <seb_kuzminsky> yes, but is yours a pile of boards and power supplies held together with tape and jumper wires??
[11:58:33] <cradek> heck even I could make fun of that
[11:58:37] <CaptHindsight> I either bring a DNA printer or an SLS
[11:58:54] <seb_kuzminsky> awesome!
[11:59:24] <CaptHindsight> see if NTULINUX wats to come
[11:59:31] <CaptHindsight> wats/wants
[11:59:41] <cradek> hm I bet I need to find a useful laptop by then
[12:07:45] <jepler> ooh I'll bring my broken delta and make someone else take it home
[12:07:52] <jepler> unless they fix it for me, in which case I'll take it home
[12:08:22] <cradek> hey we could work on gantry homing yet again, now that it would just go in master
[12:08:40] <seb_kuzminsky> aww yeah
[12:08:57] <seb_kuzminsky> i hope dewey can come this year
[12:09:50] <cradek> ooh me too
[12:09:53] <cradek> I don't think I've ever met him!
[12:09:59] <seb_kuzminsky> me neither
[12:25:10] <skunkworks> I thought dewey had gantry homing working in JA
[12:28:21] <seb_kuzminsky> i think he did part of what cradek invisioned
[12:35:55] <seb_kuzminsky> skunkworks: cradek wants the coupled joints to wait for each other at each step of the homing process, i think the current one just waits before the final move to Home
[12:36:28] <skunkworks> ah
[12:49:53] <JT-Shop> seb_kuzminsky: yea, I'm waiting till free time in the morning
[13:19:51] <cradek> seb_kuzminsky: yes I think he did one of the moves, where I had pictured that behavior for all of them
[13:20:13] <cradek> so maybe it would be easy to build on what dewey did
[13:52:48] <skunkworks> for some definition of easy?
[14:08:01] <jepler> easy enough that we'll assign it to sam
[14:08:56] <skunkworks> :)
[14:08:58] <skunkworks> zlog
[14:09:03] <cradek> ooh can we do that?
[14:15:42] <skunkworks> kwallace, what was the input resistance of the 540?
[14:15:59] <skunkworks> (for the charge pump)
[14:17:09] <skunkworks> * impedance..
[14:27:49] <KGB-linuxcnc> 03Chris Radek 05epp-parport-g540 5b06fa3 06linuxcnc 10docs/src/hal/parallel-port.txt Describe port type = epp * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5b06fa3
[14:33:55] <cradek> JT-Shop: I also added docs about using more than one parport - in retrospect it probably should have been a separate commit. look ok to you?
[14:36:40] <JT-Shop> looks good to me
[14:36:48] <cradek> thanks
[14:37:08] <JT-Shop> thanks for fixing that
[14:37:21] <cradek> :-)
[14:45:31] <skunkworks> Hmmm - interesting. I created a quick config using stepconf. All I did was put the chargepump on pin 16. When linuxcnc starts up - the charge pump fires for a second before the gui comes up.
[14:45:48] <skunkworks> (seeing it on a scope
[14:46:10] <skunkworks> I have not looked at the config yet
[14:46:24] <jepler> "fires" with a bunch of edges, or just one edge?
[14:46:55] <jepler> on a real physical scope I assume
[14:47:14] <skunkworks> bunch of edges. (just like when you pull it out of estop)
[14:47:21] <skunkworks> (square wave)
[14:47:45] <jepler> that's a bit of a surprise!
[14:48:11] <kwallace> skunkworks, I can pull the 540 out and check it.
[14:50:12] <kwallace> I recall the impedance is pretty low with a direct connection to a capacitor and a diode drop to ground.
[14:52:10] <jepler> PR38628 Arrange to share things among multiple contexts (Glx)
[14:52:10] <jepler> Otherwise, problems arise the second time a View is created; this is
[14:52:10] <jepler> now done by glcanvas.
[14:52:11] <jepler> oops
[14:52:18] <jepler> I meant:
http://paste.ubuntu.com/20215398/
[14:52:38] <skunkworks> I think I have a good test here - I have the bios set to spp and when I add a resistor (600ohm) the voltage drops to a few
[14:52:41] <jepler> this setup looks sane. does iocontrol assert user-enable-out at startup?
[14:53:20] <skunkworks> jepler, I don't think I will have time to finish the testing today. Have to pick it back up tomorrow.
[14:53:36] <jepler> skunkworks: np, we appreciate the time you do spend testing for us!
[14:53:55] <skunkworks> I don't know how I would test as the gui isn't up yet.
[14:54:18] <skunkworks> this is 2.7.5
[14:54:46] <skunkworks> I could net the io to physical pins I guess
[14:56:44] <skunkworks> bbl
[14:57:29] <jepler> well I guessed at all the places in ioControl.cc that the pin can change and those prints don't show it changing to 1 until I hit the estop reset button in axis
[14:59:01] <mozmck> I should check into the charge-pump firing for a second early on myself. I get a quick relay click sometimes on my setup when starting up, and I'm using a 7i92. Hasn't been much of a problem so far and I've been too busy to think about it.
[15:01:37] <jepler> charge-pump.enable bit in (default: TRUE)
[15:01:37] <jepler> If FALSE, forces all 'out' pins to be low
[15:01:44] <jepler> for some reason, the default value of charge-pump's enable bit is TRUE
[15:04:47] <kwallace> Isn't the default true so one doesn't need to arrange for an enabler -- it just works?
[15:05:58] <cradek> doesn't it only start pumping after halcmd start, which means all the other IO is also in its initial well-defined state?
[15:06:44] <jepler> cradek: yes that's how it's supposed to be
[15:08:34] <cradek> http://imgur.com/c4jt321
[15:11:02] <kwallace> The parport pins toggle when the OS driver loads, which is why we need the charge pump in the first place. C-22?
[15:13:13] <jepler> charge pump's output pins are false in the first thread iteration, among other things tested by this new proposed test:
https://emergent.unpythonic.net/files/sandbox/0001-tests-a-basic-test-of-charge-pump.patch
[15:13:39] <skunkworks> It happened every time I started linuxcnc
[15:14:38] <jepler> hmmm
[15:14:42] <seb_kuzminsky> jepler: the readme is wrong
[15:15:01] <jepler> seb_kuzminsky: of course it is.
[15:15:21] <jepler> "enable signal is stable" -> "is true"?
[15:15:29] <jepler> or something besides that?
[15:15:59] <jepler> .. I put a 'halcmd show pin' in my stepconf .hal file just before the end...
[15:16:02] <jepler> Component Pins:
[15:16:05] <jepler> Owner Type Dir Value Name
[15:16:05] <seb_kuzminsky> +regression test for components: watchdog
[15:16:06] <jepler> so something's rotten in the province of scandanavia
[15:16:09] <jepler> 24 bit IN TRUE charge-pump.enable <== estop-out
[15:17:11] <jepler> aha I have additional knowledge for you
[15:17:54] <seb_kuzminsky> next you should write a test for updog
[15:18:12] <jepler> at some point we foolishly added code to copy a value from a pin to a signal at attachment time
[15:18:15] <jepler> http://paste.ubuntu.com/20218593/
[15:18:55] <jepler> if you subsequently connect signal x to a writer that would otherwise be driving its signal FALSE, it stays TRUE
[15:21:27] <jepler> if you connect a FALSE pin to a signal first, regardless of its drive direction, then the FALSE value gets copied
[15:36:14] <mozmck> jepler: I think I've gotten bitten by that. I had at least one case where I had to make sure I connected the writer first and then the reader pins.
[15:39:14] <jepler> commit 51a0afc76394
[15:40:19] <jepler> I was just talking IRL to cradek, and brainstormed the following modification: The copy-from-pin-to-sig behavior should happen for the first *writer*, not for readers
[15:40:47] <mozmck> That makes sense.
[15:40:53] <seb_kuzminsky> sounds good
[15:41:05] <cradek> and rw pins should do ... something
[15:41:29] <mozmck> If readers do it, then each of multiple readers could successively set the state of the signal
[15:41:47] <cradek> no, currently only the first one does
[15:42:04] <mozmck> Ah, I see.
[15:44:05] <mozmck> maybe IO pins would be counted as writers for this case?
[15:44:33] <mozmck> Since IIRC you can't have an OUT and IO on one signal?
[15:44:51] <cradek> the normal/idle state of an IO pin is not writing
[15:45:04] <cradek> they only periodically push out a new value onto the bus
[15:45:10] <seb_kuzminsky> mozmck: i think a net can have at most one Out pin, and any number of IO and In pins
[15:45:12] <cradek> so I think they are usually more like readers
[15:45:46] <jepler> you can't mix Out and IO though
[15:45:46] <cradek> seb_kuzminsky: I think you can't have a writer and an IO pin netted together
[15:46:07] <cradek> a writer always writes so the IO would never get its chance
[15:46:18] <mozmck> Yes, so a net will have either an OUT, or one or more IO
[15:46:56] <mozmck> So for a net with IO pins the first IO's state would be used?
[15:47:00] <seb_kuzminsky> cradek: you're right:
http://linuxcnc.org/docs/2.7/html/hal/basic-hal.html#_net
[15:47:24] <seb_kuzminsky> multiple IO pins are allowed as long as there are no Out pins
[15:47:28] <jepler> + if (pin->dir != HAL_IN && ( sig->writers == 0 ) && ( sig->bidirs == 0 )) {
[15:47:42] <jepler> so I think this variant would make the first non-IN pin's value get copied to the signal
[15:47:58] <jepler> could also write dir == HAL_OUT && sig->writers == 0, make the first OUT pin's value get copied to the signal
[15:47:59] <mozmck> seb_kuzminsky: yes - I ran into that yesterday. I use IO pins a good bit and accidentally put an OUT pin on a net and linuxcnc let me know about it.
[15:48:16] <jepler> seems like the latter option, dir == HAL_OUT, makes the most sense
[15:48:23] <cradek> yes
[15:48:58] <jepler> then I just need to test direction and not counts of anything, yes?
[15:49:11] <cradek> so if you net an in before the out on that net, the in's value will change twice
[15:49:29] <mozmck> will the dir for an IO pin be HAL_OUT?
[15:50:16] <cradek> jepler: did you look for "ref: [Emc-developers] PID bidirectional pins. Mar 16 2014"?
[15:50:17] <jepler> I believe the different direction values are HAL_IN, HAL_OUT, HAL_IO
[15:50:29] <cradek> it might say what problem he was trying to solve
[15:50:29] <jepler> cradek: no, I didn't read the commit message that far
[15:50:51] <jepler> if it was about bidir pins then my change will make a regression
[15:51:18] <jepler> however, there is one more problem: the moment you link an HAL_IO pin which has a value preset
[15:51:19] <cradek> this feels like a here be dragons
[15:51:21] <jepler> (like pid.0.Pgain set to 1) to a signal (which defaults to 0), the preset value is lost.
[15:51:50] <jepler> well it's AFU if pgain is really an IO pin but I lost that battle long ago
[15:55:19] <jepler> if you loadrt pid, setp pid.pgain, net pid.pgain -> you are a bad person and you should feel bad
[15:55:40] <jepler> the right operation would be load, net, sets, assuming sets works right when IO pins are attached to the signal
[15:56:03] <jepler> halcmd: net fml tristate-bit.0.out
[15:56:03] <jepler> halcmd: sets fml 1
[15:56:03] <jepler> halcmd:
[15:56:05] <jepler> oh good you can
[15:58:21] <jepler> but I'm back to the pin_dir != HAL_IN use case
[15:58:44] <jepler> that still fixes this charge pump problem; and however wrong I think mah's workflow for IO pins is it doesn't break that workflow
[16:14:19] <jepler> updated:
https://emergent.unpythonic.net/files/sandbox/0001-tests-a-basic-test-of-charge-pump.patch https://emergent.unpythonic.net/files/sandbox/0002-hal-revise-rules-about-copying-values-to-signals-on-.patch
[16:16:48] <jepler> but I have a feeling this shouldn't be changed in 2.7. that tree's had enough troubles lately.
[16:16:54] <mozmck> I like your warning note. Will the deprecation only affect HAL_IO pins?
[16:17:43] <jepler> the 0002- patch changes the behavior for IN pins right now
[16:18:14] <jepler> it's IO pins I think should eventually be changed, but not right now since advice to solve a problem with IO pins in this way is "out there"
[16:18:35] <mozmck> Yes, but your note says the behavior may change or be removed in the future - but it only says that if pin->dir == HAL_IO
[16:19:13] <mozmck> ok
[16:29:03] <andypugh> What’s the issue being talked about here?
[16:29:38] <jepler> andypugh: charge-pump is active for a short time when just starting linuxcnc
[16:29:42] <jepler> particularly on stepconf configs
[16:30:10] <andypugh> Curious
[16:31:39] <andypugh> The “enable” bit does default to “true”, is that why
[16:31:41] <andypugh> ?
[16:32:56] <jepler> that's part of the "why"
[16:33:26] <jepler> but it's linked up to iocontrol.user-enable-out, which defaults to "false"
[16:33:47] <andypugh> It isn’t _necessarily_ connected to that.
[16:33:52] <jepler> it is by stepconf
[16:34:52] <andypugh> I assume that it defaults to true because it isn’t necessarily enabled by anything. It’s just a “base thread is running” signal
[16:36:01] <jepler> right I'm pretty sure that's the motivation
[16:36:30] <jepler> but the real problem is this code that copies the value from a pin to a signal when it is linked.
http://paste.ubuntu.com/20228445/
[16:37:01] <jepler> see how and2.0.out got set to TRUE regardless of its outputs (note: hal threads not running at this point)
[16:37:29] <jepler> and the result is different if you had written: net x and2.0.out => charge-pump.enable
[16:38:32] <andypugh> FALSE would be equally wrong…
[16:38:55] <jepler> happily, those are the only two choices
[16:39:30] <andypugh> setp and.2.out MAYBE
[16:40:09] <jepler> I think if you've got a net N that you link with an OUT pin PO and an IN pin PI, the value of PO before it was linked is a more defensible answer than the value of PI before it was linked.
[16:40:24] <andypugh> Do we have any feel for what the reaction time of a hardware charge-pump minotor circuit is?
[16:40:42] <jepler> short, I think, compared to task and iocontrol coming up as non-realtime processes
[16:41:15] <andypugh> I assume there is some good reason for iocontrol?
[16:41:50] <cradek> I'd guess a few 1s or 10s of pulses would enable a charge pump.
[16:42:16] <cradek> 1 probably shouldn't
[16:42:20] <jepler> charge pump typically runs in base-thread, so you might have 10 to 25 pulses from it before servo-thread runs
[16:42:22] <cradek> but some of them are probably bad
[16:42:44] <jepler> so even if you contemplate "fixing" this by saying, well, don't hook a non-RT signal to charge-pump, ...
[16:43:14] <jepler> if it's from a slower thread you would still have a glitch
[16:44:41] <andypugh> Do we actualy start the threads before iocontrol and task come up?
[16:44:50] <jepler> yes
[16:44:52] <andypugh> ‘Appen we shouldn’t?
[16:45:13] <jepler> maybe in an ideal world
[16:45:23] <jepler> but I don't think that's feasible
[16:45:35] <jepler> because task needs to exchange messages with motion before it finishes coming up
[16:49:48] <andypugh> Does it help that that interchange is not taking place in HAL?
[16:51:08] <jepler> between task and motion?
[16:51:45] <jepler> hal threads have to be running for that interchange to occur, otherwise motion-command-handler isn't running
[16:52:12] <jepler> I also don't think this is a question about task or iocontrol. this is a question about hal.
[16:55:05] <jepler> another attempt to state the problem:
http://paste.ubuntu.com/20230638/
[16:55:31] <andypugh> I think I get the problem.
[16:55:38] <andypugh> (Or part of it)
[16:57:11] <andypugh> I am not proposoing this as a solution, just a thought experiment. If you delayed the addf of all but motion until task and iocontrol were up, things might work better.
[16:58:52] <jepler> hm if I were to design a lathe I think I'd call it TACITURN
[17:01:58] <andypugh> Actually, maybe a simpler idea (and probably even harder in practice) might be to run the servo thread once before running the base thread. Or is that solving a different puzzle?
[17:03:00] <andypugh> I guess it might be no help to run the base thread if iocontrol is not loaded yet.
[17:04:06] <andypugh> (sorry, that sentence makes no sense, it was meant to say “servo thread”)
[17:05:16] <andypugh> 28.8C and 65% humidity in my front room. I am not enjoying it.
[17:07:21] <jepler> yuck. 36C outside here, but a whole different story inside of course.
[17:17:22] <jepler> In the yahoo groups geckodrive files area there's "_G540 SCHEMATIC.pdf". It shows a 200-ohm series resistor to an ILQ74 optoisolator
[17:22:55] <jepler> (I'm frankly stunned that copies of this file don't show up on google)
[17:41:42] <andypugh> I tried, and found a number of Commodore Pet schematics instead
[17:45:56] <skunkworks> I should be able to see if cradeks changes to the Hal printer port driver force it to epp tomorrow
[17:46:56] <skunkworks> I have witnessed a 600ohm resistor pull pin 16 down to 2v or so.
[17:47:36] <skunkworks> Just ran out of time
[17:48:10] <skunkworks> I left it building the g540 branch
[17:49:22] <kwallace> My G540 picture shows a series capacitor followed by a bridge rectifier driving an LTV846 opto input.
[17:49:32] <kwallace> http://www.wallacecompany.com/machine_shop/G540/G540_upper_bottom_z-1b.png
[17:50:04] <Tom_itx> wonder why the G540 is the odd duck compared to the other gecko drivers
[17:50:57] <skunkworks> The charge pump signal is on long enough that I.
[17:51:24] <skunkworks> I can see it on an analog scope.. second or 2
[17:52:03] <skunkworks> As far as I know the 540 is the only thing that has a charge pump
[17:53:42] <mozmck> Tom_itx: The G540 is basically a breakout board with 3 or 4 G250 drives. Most other breakout boards buffer the signals, but it sounds like the G540 does not at least for the charge pump.
[17:54:35] <andypugh> Does anyone know of a neat way to get values back into G-code from an external executable?
[17:55:11] <mozmck> andypugh: I do it with motion.analog-in pins
[17:55:26] <jepler> kwallace: I assume that just below the "KL4" dual diode package is another cap?
[17:55:50] <kwallace> Yes
[17:55:56] <andypugh> M100 calling Python looks like a start, but can Pythoin set G-code params? The stdglue routines do it (import emcannon, from interp import * ) but those imports don’t seem to work in an M100 file
[18:00:48] <mozmck> andypugh: I guess this external program does not have HAL pins? Maybe you could make a simple component which take the values from the external program and places them on pins, then connect to motion.analog/digital-in pin and read with M66
[18:01:30] <andypugh> Yes, that was one way I suggested. But I am trying to find a “neat way” :-)
[18:04:58] <andypugh> I think that my question has morphed into “How can remap use “import emccanon” and my Python code can’t?
[18:06:21] <kwallace> jepler, you probably figured it out, but I think it goes like:
http://www.wallacecompany.com/tmp/Screenshot_G540_CP.png
[18:07:58] <cradek> welp that isn't going to work on OC without a pullup...
[19:03:52] <Tom_itx> mozmck yes i knew there was something odd about it, just wasn't sure what since i use the 203v's
[19:04:15] <Tom_itx> why would you have gcode imbedded in an executable?
[21:10:37] <skunkworks_> zlog
[21:32:09] <jepler> kwallace: either way, it is clear enough why an OC pin wouldn't drive the CP. What I had never realized is that so-called "EPP" mode reliably turned those same pins from OC to totem-pole.
[21:38:03] <kwallace> I think the NetMOS datasheets indicate the OC to totem feature.
[21:39:41] <jepler> I found the datasheet for the superio on my current motherboard and I haven't found that specified yet
[21:43:31] <skunkworks_> it must have a pretty high value resistor to v+
[21:43:40] <skunkworks_> in OC mode
[21:44:17] <skunkworks_> I will take some pictures tomorrow
[21:59:08] <kwallace> Off hand I'm not finding detailed information. I did find:
http://www.asix.com.tw/FrootAttach/datasheet/MCS9815_Datasheet_v201.pdf
[22:01:46] <jepler> IEEE 1284-2000 says that legacy ports used OC but doesn't actually seem to specify what a 1284-compatible port does in compatible mode on those pins!
[22:03:03] <kwallace> There are pin descriptions on page 8 and a key to the direction designations on page 12. I assume anything labeled I/O is totem-able.
[22:03:39] <jepler> in that datasheet, "direction" for the pins in question is given as "OD_O (PU)" defined elsewhere as "Open Drain Output
[22:03:42] <jepler> –
[22:03:45] <jepler> Internal Pull Up"
[22:04:00] <jepler> e.g., pins nINITA/B
[22:07:28] <kwallace> Ah, sure enough.
[22:09:44] <kwallace> At 12 ma = 400 Ohms. I would think they would want a fairly high resistance so one could pull it low externally if needed, but just a wild guess.
[22:10:53] <kwallace> Thinking more,a pull down would be silly.
[22:18:34] <kwallace> Just in case there mig be some useful:
http://retired.beyondlogic.org/ecp/ecp.htm
[22:22:32] <kwallace> might
[23:29:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/test-code-dedup 9647bff 06linuxcnc 03lib/python/linuxcnc_util.py add a linuxcnc_util python module * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9647bff
[23:29:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/test-code-dedup eee0bff 06linuxcnc 10tests/lathe/test-ui.py tests/lathe: use linuxcnc_util for helper functions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eee0bff
[23:29:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/test-code-dedup 2834af9 06linuxcnc 10tests/halui/jogging/test-ui.py 10tests/halui/mdi/test-ui.py tests/halui: remove unused linuxcnc interface code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2834af9
[23:29:36] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/test-code-dedup d0927be 06linuxcnc 10tests/interp/mdi-oword-m66/test-ui.py tests/interp/mdi-oword-m66: remove dead linuxcnc interface code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d0927be
[23:29:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/test-code-dedup e29ff0b 06linuxcnc 10tests/interp/subroutine-return/test-ui.py tests/interp/subroutine-return: use linuxcnc_util interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e29ff0b
[23:29:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/test-code-dedup af82c8d 06linuxcnc 10tests/io-startup/test-ui.py tests/io-startup: use linuxcnc_util interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=af82c8d
[23:29:48] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/test-code-dedup 5006c06 06linuxcnc 10tests/motion/jogwheel/test-ui.py tests/motion/jogwheel: remove unused interface code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5006c06
[23:29:52] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/test-code-dedup 640570a 06linuxcnc 10tests/tlo/test-ui.py tests/tlo: remove unused interface code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=640570a
[23:29:56] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/test-code-dedup f72949b 06linuxcnc 10tests/toolchanger/m61/test-ui.py tests/toolchanger/m61: remove unused interface code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f72949b
[23:37:58] <seb_kuzminsky> i'm not really a python coder, i'd appreciate feedback on that branch, should be a quick review
