Back
[06:45:23] <skunkworks> zlog
[07:44:21] <skunkworks> you should be able to follow these directions with the livecd - right?
[07:44:26] <skunkworks> *linuxcnc livecd
[07:44:27] <skunkworks> http://linuxcnc.org/docs/html/getting-started/getting-linuxcnc.html#_installing_on_debian_wheezy_with_preempt_rt_kernel
[07:59:30] <skunkworks> sorry about this..
[07:59:31] <skunkworks> http://www.practicalmachinist.com/vb/general/linuxcnc-its-main-advantages-321126/
[08:15:58] <archivist> I bet none of those ever retrofitted a hobbing machine, dunno if the usual commercials can do that easily :)
[08:43:55] <cradek> well I made it through one page of that. I assume the other 3 pages are similar...
[08:45:34] <cradek> skunkworks: yes, except you might want to uninstall the rtai kernel afterwards, and also the rtai linuxcnc.org repository from the apt sources
[08:55:01] <mozmck> skunkworks: I see the "expert" showed up on that thread ;-)
[08:55:11] <skunkworks> yes
[08:55:19] <skunkworks> 10k hours invested..
[08:55:29] <skunkworks> cradek, thanks
[08:55:33] <mozmck> has anyone ever seen one of his machines yet?
[08:57:35] <skunkworks> no. In one thread he said that he couldn't because of customer confidentiality or something like that
[09:19:41] <mozmck> skunkworks: adama's post #60 "you better hope my free versions as bad as you wish it is :-) Else, your just another bankrupt in progress :-)"
[09:19:56] <skunkworks> heh
[09:20:03] <kimi> Hello
[09:20:13] <kimi> anybody familiar with macro-programming ?
[09:27:32] <cradek> kimi: can you ask a more specific question?
[09:28:21] <7YUAA94JF> Hello, I used to go to mah or psha for irc logs, but these don't seem to be valid anymore. Are there up to date links?
[09:28:30] <jepler> zlog:
[09:28:35] <jepler> 7YUAA94JF: ^^^
[09:29:17] <7YUAA94JF> Thank you.
[09:30:06] <kimi> Hello
[09:30:11] <kimi> thanks for feedback
[09:30:36] <kimi> now, i am using 4-axis cnc machine
[09:30:44] <kimi> so everytime to post a .nc program i need to convert it through a software
[09:36:20] <kimi> Helllo?
[09:37:09] <skunkworks> I don't think anyone on here knows... You are getting some help on the other channel..
[09:42:01] <jepler> seb_kuzminsky: this must be related to the thing you were saying about nml aborts and non-determinacy:
https://github.com/LinuxCNC/linuxcnc/issues/49
[10:53:10] <seb_kuzminsky> it probably involves the Task abort code
[10:53:38] <seb_kuzminsky> one of the things we do on Task Abort is discard interp_list, which might be the cause of the issue micges observed
[10:54:30] <jepler> right
[10:54:40] <jepler> that's exactly the scenario that my two brain cells were rubbing together
[10:54:58] <seb_kuzminsky> yeah
[10:55:43] <seb_kuzminsky> the fix for the stale-statbuf bug that zultron reported, that i hastily sketched out over beers last weekend, suffers from a similar problem
[10:57:17] <seb_kuzminsky> i proposed doing much of convert_stop()'s M2/M30 handling in Inter::on_abort(), but that handling involves putting stuff on interp_list (to ask Canon to clean itself up), and our many spurious aborts during all kinds of non-aborty state transitions made that indeterminate and unpredictable and thus impossible to test properly
[10:57:39] <seb_kuzminsky> i have the best words
[10:59:29] <jepler> hmph C++11
[11:01:45] <seb_kuzminsky> for solving my problem (but not micges') i had imagined (against my better judgement) to add another global state flag to Task, to be set on Abort, after clearing interp_list and before calling Interp::on_abort(). This new flag would be called something like "drain_interp_list", and when True would suspend Task from reading any NML input from the UIs until it had completely drained interp_li
[11:01:52] <seb_kuzminsky> st of the aborty canon calls Interp put in it
[11:02:23] <seb_kuzminsky> that way it won't start a new abort until it's done handling the earlier abort
[11:02:31] <seb_kuzminsky> and the indeterminacy goes away
[11:02:43] <seb_kuzminsky> at the cost of a slightly longer (but more correct) abort path
[11:03:21] <jepler> some days I fantasize about just deleting task and replacing it with something else
[11:03:36] <seb_kuzminsky> haha yeah
[11:03:55] <seb_kuzminsky> it only it wasnt so useful for all our users continuing to successfully make correct parts all the time
[11:03:58] <seb_kuzminsky> *if
[11:04:01] <jepler> a big ball of twine that has been submerged in water long enough to start to mold and decay for instance
[11:11:57] <skunkworks> that is harsh.. ;)
[11:12:11] <seb_kuzminsky> no, that's very charitable
[11:12:48] <jepler> I mean jute or hemp twine, not nylon or other synthetic
[11:13:18] <jepler> huh if you google "jute" you get nutritional information(!), I didn't think it was something you were supposed to eat.
[11:13:30] <jepler> 32 calories per cup (87g)
[11:13:42] <jepler> surprisingly low in dietary fiber (1.7g)
[11:14:23] <skunkworks> Squirrel!
[11:15:51] <jepler> huh apparently there is a jute used for culinary purposes
https://en.wikipedia.org/wiki/Jute#Tossa_jute_.28Corchorus_olitorius.29 TIL
[11:16:43] <seb_kuzminsky> you vegetarians are weird
[11:21:19] <seb_kuzminsky> jepler: about #49, maybe the "drain_interp_list" flag could help there too - we could set it in emcTaskPlanInit(), just before calling interp.execute on the rs274ngc_startup_code
[11:22:17] <seb_kuzminsky> unless someone objects i'll try to implement it in the stale-statbuffer branch, and if it works there i'll try to develop a test for #49 and see if it fixes that one too
[11:22:25] <jepler> that sounds fully awesome
[11:24:23] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #49: Jeff and I discussed a possible fix here:... 02
https://github.com/LinuxCNC/linuxcnc/issues/49#issuecomment-224003305
[18:53:08] <jepler> this is interesting (from a just-approved post on the forum):
http://www.openplcproject.com/
[18:53:20] <jepler> and after you've seen that page for 30 seconds you'll know as much as me
[19:10:11] <PCW> wasn't there another open PLC project a year or 2 ago?
[19:12:16] <jepler> I would not be surprised. My memory is short.
[19:12:58] <jepler> you should write a hostmot2 firmware for your ethernet boards that includes a web-based ladder editor and saves the ladder right on the EEPROM. in your free time.
[19:13:47] <jepler> probably wouldn't technically be hostmot2 anymore at that point
[19:17:29] <PCW> Probably doable with the twiddler interface in my spare time...
[19:17:41] <Tom_itx> key word... in your free time :D
[19:20:13] <andypugh> The email from the chap who created a PLC to study SCADA vulnerabilites was a bit odd. I am not sure how useful it is to create a PLC with known problems. However it is a genuine concern. I went to a talk from a chap who had managed to get control of the Hoover Dam penstocks and the sprinklers in the Bodlean Library. (
https://vimeo.com/133661841)
[19:20:50] <PCW> jepler: eth-packet-loss triggered a firmware bug in the the Ethernet firmware (fix but no bitfiles other than my test one made yet)
[19:21:53] <PCW> I must not have looked at the LEDs when I tested the scratch registers
[19:23:41] <PCW> (immediate error led if you write to any of the scratch registers)
[20:21:10] <jepler> PCW: OK, I must not have noticed the error LED here
[20:21:25] <jepler> PCW: is there a different location I can use for scratch that would work around the error?
[20:23:07] <PCW> no I screwed up the parser decoding of space 4? so write to the scratch area overlaps the timer area
[20:25:52] <jepler> someplace in space 0 (hostmot2 address space) maybe?
[20:26:10] <PCW> The VHDL and CPU parser source is fixed in V16 (in 5i25.zip or 7I80.zip)
[20:26:41] <jepler> now that we know this I'm not sure we can/should merge it to 2.7, if everybody with an ethernet card has to get a new firmware that's bad
[20:27:45] <PCW> its not really harmful currently (other than the LED)
[20:32:01] <PCW> I'll make new bitfiles this week sometime
[20:32:02] <PCW> V16 firmware also has support for reception of broadcast ping and UDP packets
[20:32:04] <PCW> but needs the netmask written to the EEPROM for use with the EEPROM IP address
[20:32:06] <PCW> (the ROM IP address has a fixed 255.255.255.0 netmask)
[20:33:47] <jepler> for instance, knowing that we don't really use TRAM, I could use space 0 addresses 0x7bf8 and 0x7bfc instead
[20:34:11] <jepler> but if documenting that for versions <16 the error LED will light even if there's no error is OK, I suppose
[20:34:53] <PCW> I ran into this because I added WDtimeout to the things that can light the error LED
[20:38:25] <PCW> I probably should have added a couple scratch registers to HM2 a long time ago (thet are useful for general sanity checking at startup)
[20:39:56] <PCW> you have 256x 32 bit scratch registers in the IDROM but that might be bad on the second startup :-)
[20:45:05] <seb_kuzminsky> PCW: can you make the fix in the "v0.8" firmwares that we auto-build and push out to users in debian packages? or has the day for that old version come and gone?
[20:46:02] <PCW> yeah its just 3 or so changed files
[20:47:17] <PCW> the actual bugfix only needs an updated etherhm2.vhd ROM
[20:49:39] <PCW> the Error LED on WD bite needs the updated hostmot2.vhd and TopEthernet16Hostmotm2.vhd
[20:50:37] <PCW> I plan to add this (error LED illuminated on WD bite) to most top level files eventually
[20:55:13] <PCW> Next step is stored procedures so a broadcast read request can read all devices process data ( and sync DPLLs ~simultaneously )
[20:56:03] <jepler> it sounds cool, not sure we'll achieve support for it in linuxcnc soon
[20:56:12] <jepler> maybe you have other software and customers that will benefit though
[20:56:43] <PCW> Yeah this is long term
[20:58:34] <PCW> there are still some oddments with eth-packet-loss that should be addressed (or at least documented) before its merged
[21:00:22] <jepler> the main thing still on my mind is testing and then documenting what happens with encoders and index latch
[21:02:53] <PCW> Yeah dealing with possible write failures is interesting...
[21:02:55] <PCW> The issues I see are sserial problems and strange packet timeout behavior on one system
[21:05:39] <jepler> my plan is to make a virtual encoder in an avr
[21:06:15] <jepler> it'll at least do quadrature A/B/Z and maybe emulate a homing switch too, probably take a velocity command over non-realtime usb
[21:08:49] <PCW> practically speaking I would expect packet errors to be very rare
[21:09:32] <PCW> but certainly should not case a fatal error as they do before eth-packet-loss
[21:18:20] <jepler> oh ugh there's a different error case than the one I was fixated on, wrt index
[21:19:11] <jepler> if the read that first sees index-latch cleared is the one that goes missing, linuxcnc risks setting index-latch in the following force-write and not registering that index was seen
[21:19:52] <seb_kuzminsky> http://imgur.com/B59CvVb
[21:20:36] <jepler> seb_kuzminsky: pretty much
[21:22:14] <seb_kuzminsky> i'm looking more closely at how the interp_list evolves during startup and during abort, and it's making my skin crawl
[21:22:45] <seb_kuzminsky> we enqueue all this useful-seeming initialization, then discard it beacuse of a handful of surplus aborts durning startup...
[21:23:16] <jepler> so besides us advising that it's a bad idea and put all modal settings at the top of your part program, ...
[21:23:30] <jepler> ... the interpreter startup code also just doesn't work as documented when the NML starts flying?
[21:23:46] <seb_kuzminsky> i'm not sure yet
[21:41:11] <PCW> if you only set the latch on index if it reads clear and keep writing it true until it reads true does that help?
[21:41:13] <PCW> There's a race condition where you could lose the index detect (but that race condition has always been there)
[21:46:07] <PCW> on homing is seems like you avoid the race condition by the time between the home switch (arming latch on index)
[21:46:09] <PCW> and the actual index occurrence
[21:50:05] <PCW> on things like rigid tapping where the arming is asynchronous is seems like you could miss the index but that just means you wait for the next one
[21:51:45] <PCW> or maybe I'm not thinking this through because its dinner time
[21:51:53] <PCW> bbl dinner
[22:56:21] <seb_kuzminsky> yes, i'm convinced now that our startup is just totally racy and broken
[22:57:12] <seb_kuzminsky> take a look at Task's main()
[22:57:27] <seb_kuzminsky> run-from-line, if you will, starting here:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/task/emctaskmain.cc#L3281
[22:58:11] <seb_kuzminsky> emctask_startup() instanciates Interp, which runs Interp::init():
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/rs274ngc_pre.cc#L802
[22:59:13] <seb_kuzminsky> as you can see, Interp::init() calls INIT_CANON() and SET_G5X_OFFSET() and SET_G92_OFFSET(), which all enqueue NML commands on interp_list.
[22:59:43] <seb_kuzminsky> it also optionally runs [RS274NGC]STARTUP_CODE from the ini file, which will enqueue even more stuff on interp_list
[23:00:01] <seb_kuzminsky> (we're getting close to the root cause of #49 now)
[23:01:31] <seb_kuzminsky> after emctask_startup() returns to Task's main(), which right away enters Estop by calling this:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/task/emctask.cc#L291
[23:02:24] <seb_kuzminsky> entering estop causes an Abort, which clears the interp_list:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/task/emctask.cc#L176
[23:02:41] <seb_kuzminsky> it's enough to drive a man to drink
[23:05:34] <mozmck> issue #49 is not very clear to me. the image micges posted is gone
[23:06:15] <mozmck> It sure does sound like things are a bit haywire in there though!