Back
[01:13:45] <TanayG_> Hello! I am Tanay (:
[10:14:25] * jepler wishes Nicklas Karlsson and others the best with their ideas, but I don't think the result would be linuxcnc.
[10:15:29] <jepler> (also they should take a careful look at the situation in mach4, where they're seemingly having a real struggle after deciding to move all the realtime stuff into micros, fpgas & whatnot, to avoid those mistakes)
[10:16:54] <cradek> that sounds like the same answer as every time someone has that same idea
[10:37:11] <mozmck> The communications delays between Mach3 and hardware is a very real problem.
[10:37:32] <mozmck> I haven't used Mach4, but it doesn't sound like it is much better.
[10:54:22] <cradek> do you think the "very real" problems are fundamental (bad design) or accidental (just bugs)?
[10:58:58] <jepler> I don't know. Most of my knowledge comes from when I can't resist clicking on the mach-related links that skunkworks gives us now and then, which I'm sure reflect the worst bits and not the typical bits..
[11:03:27] <skunkworks> Guilty
[11:03:34] <mozmck> :-)
[11:03:59] <mozmck> I think the problems are fundamental. At least with Mach3 and the ESS, communication happens only about every 100ms
[11:04:34] <skunkworks> and it buffers seconds worth of motion
[11:04:47] <mozmck> So the ESS (and other hardware solutions) must implement homing, limits, etc.
[11:05:34] <skunkworks> seems there could be a way to send an abort that circumvents the buffered data - which may be what mach4 is supposed to fix. That has to all be done in the hardware though..
[11:05:35] <mozmck> If you need something else realtime - it has to be implemented in the hardware.
[11:05:46] <cradek> it seems like the worst bit is how what features you get and the quality of their implementation depends on whose hardware you buy
[11:06:01] <mozmck> There is an abort, but again - it might take 100ms to get there.
[11:06:04] <cradek> what if one vendor has the best homing and another has the best threading? you have to pick I guess.
[11:06:48] <jepler> just have a big knife switch you throw after homing to switch to the other board
[11:07:02] <mozmck> Yes, and it seems like Mach4 will be very much the same in that regard. I did hear that the communication cycle can be sped up a lot, but it's still not realtime.
[11:07:58] <jepler> on a human scale, 100ms isn't bad. if a jogged axis always begins to decelerate within 100ms of key release, that's going to be satisfactory.
[11:08:10] <mozmck> True.
[11:08:36] <cradek> but that sounds like the minimum delay, not the maximum
[11:09:08] <jepler> with a Free software project and programmable smart hardware you would be able to evolve the two in lock step, and so you wouldn't be stuck with one board having better homing and one having better threading
[11:09:58] <cradek> that's sure true
[11:10:00] <mozmck> cradek: that's more the maximum delay. it's a 100ms loop. There are ways to do stuff faster - but not realtime.
[11:12:52] <jepler> since PCs are just glorified video game machines, they will usually be able to do periodic tasks in 1/60s and will be declared unfit for gamers if they regularly miss those deadlines for as little as 1/10s
[11:15:47] <mozmck> Yeah, I'm not sure what the jitter can be on the 100ms loop, but probably pretty variable. The reason I said more of a maximum, is that it mostly depends when a command is issued. If you are 50ms after the last interrupt, and you issue a feedhold, it will be roughly 50ms until it gets to the hardware. If it was only 1ms after, then it will take about 99ms to get there.
[11:22:15] <jepler> there are sure a lot of different ways to think about it. I guess ultimately it comes down to whether the user's experience when pressing feed hold, releasing a jog button/key/switch, etc., is satisfactory
[11:26:49] <mozmck> Ah, yes. But, if you need to do something more realtime, then it gets to be an issue. 100ms at 250IPM = .4167 inches before something takes effect!
[11:31:12] <jepler> yeah don't implement probing that way!
[11:36:07] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes12 2b2b8cc 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt 10src/emc/usr_intf/axis/scripts/axis.py updating-linuxcnc.txt del leftover .axisrc example * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2b2b8cc
[11:36:08] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes12 997c983 06linuxcnc 10share/axis/tcl/axis.tcl 10src/emc/usr_intf/axis/scripts/axis.py axis gui: allow world wheel jog after running prog * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=997c983
[13:27:53] <cradek> jepler: "experience ... is satisfactory" made me think of #1 of
http://www.tormach.com/blog/6-things-we-didnt-expect-pathpilot/
[13:32:24] <archivist> "brought our control software in-house" grrrr forgetting to mention upstream
[13:32:47] <jepler> grinding your teeth like that is not good for dental health
[13:33:20] <cradek> for better or worse, they do maintain a totally separate fork, so that's not really wrong
[13:34:06] <cradek> it is too bad they seem to act like being derived from linuxcnc is something to obscure
[19:34:45] <jepler> whee, my new computer (i7-4790K) builds linuxcnc from clean in 34s without ccache, <4s with ccache. Pretty juicy!
[19:37:56] <seb_kuzminsky> http://media-cache-ec0.pinimg.com/736x/03/d6/82/03d6821ff13feb964e291afddf388298.jpg
[19:45:24] <jepler> :)
[22:09:41] <jepler> not as fast as an (older but 12-thread) i7-4930K, full build from clean in 23s. not quite an apples comparison, because it's also comparing g++ 4.9 on the newer system to g++ 4.7 on the older
[22:18:34] <steve_stallings> The situation with "real time" in Mach4 is both better and worse. Well implemented plug-ins and hardware can get the human response time down to 10 mS.
[22:19:26] <steve_stallings> The bad part is that this comes at the expense of shoving more of the responsiblity onto the external device, and as you said some do it better than others.
[22:19:58] <steve_stallings> Things like threading and probing depend almost entirely on the abilities of the external device.
[22:21:36] <steve_stallings> We have probing working well and are only now starting to tackle threading.
[22:24:07] <steve_stallings> Oh... and homing needs the same kind of device capabilities as probing, i.e. the real time aspect is handled in the device.
[23:01:35] <pcw_home> Preempt-RT 4.1.15-rt18-rc1 up 11 days on CoreDuo desktop with HM2-eth at 4 KHz
[23:01:36] <pcw_home> with videos, compiling, normal desktop use etc no rt errors
[23:01:38] <pcw_home> I have more than a year of uptime on the G3258 with hm2-eth at 4 KHz but 4.1.15-rt18-rc1 is the first version
[23:01:39] <pcw_home> I have had consistent error free running at 4 KHz with the Core Duo
[23:07:19] <pcw_home> I do wish I knew what motion-command-handler does than occasionally takes a loooonnnng time
[23:07:47] <pcw_home> s/than/that/
