#linuxcnc-devel | Logs for 2016-04-12

Back
[03:22:56] <ikcalB> seb_kuzminsky: fyi, We've extensively bogged around on 2 machines with the heuristic realtime delay warning removed. no unwanted side effects encountered
[03:25:25] <ikcalB> since using the linuxcnc "wheezy" version, we sometimes encounter loss of the parameters. (our machines are switched off by cutting power) does anyone know, if the ext4 settings from the wheezy installation differ from the older ubuntu one? (cannot find that on google, and don't have access to an old machine right now)
[05:39:01] <jthornton> turns out the guy is a retired EE and no one would answer his question to satisfaction on the forum so now he has a chip on his shoulder
[06:04:33] <jthornton> http://paste.ubuntu.com/15783810/
[07:09:59] <skunkworks> zlog
[07:21:28] <archivist> jthornton, to me EE is meaningless electrical or electronic or something else, changes plugs
[08:10:42] <JT-Shop> pcw_home: thanks
[08:44:41] <cradek> I agree that buying a product and then being sent to a forum staffed by volunteers for its support is bad, but in my experience that's not what mesa does.
[08:45:30] <cradek> it's also hard to accept that people really are trying to help in good faith, when they are sometimes bad at helping or bad at answering questions or don't understand the issue but try anyway
[08:45:58] <cradek> so ... I guess I sympathize a bit
[08:46:38] <cradek> mesa should be answering every email they get from people who buy their products, even if the answer is a polite nonanswer
[08:46:54] <cradek> (and I kinda have a hard time believing they aren't)
[08:47:31] <cradek> (I didn't go look for the forum threads he's talking about)
[08:55:57] <skunkworks_> sometimes it comes down to that you can't make everyone happy
[08:57:54] <cradek> yes without knowing what his questions are I'm guessing a lot...
[09:11:19] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 2606a35 06linuxcnc 10docs/src/motion/kinematics.txt kinematics.txt paste errs JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2606a35
[09:11:19] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 f757bb4 06linuxcnc 10lib/hallib/sim_lib.tcl sim_lib.tcl fix make_ddts for ddt_limit JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f757bb4
[09:11:19] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 86b4379 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py allow lowercase [DISPLAY]JOG_AXES] JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=86b4379
[09:11:20] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 8a99775 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py restore task_mode after touchoff if JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8a99775
[09:31:34] <tinkerer> unterschreibe
[09:32:13] <tinkerer> wrong window
[09:32:54] <tinkerer> but, "Instead they danced around with all kinds of irrelevant techno babble." HMMD *g*
[10:49:39] <pcw_home> well the Zotac CI323 is a something of a disappointment
[10:52:40] <pcw_home> ~250 usec latency
[10:56:18] <pcw_home> on the other hand the linuxcnc install was simple and it seems to run hm2_eth at 1 KHz OK
[11:42:30] <seb_kuzminsky> ikcalB: do you mean this commit? http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=ec56cef05b4197e1f65196b2ae297514b9b93686
[11:42:55] <seb_kuzminsky> that went into 2.7 almost a month ago, and will be part of 2.7.5 when we release that
[11:42:58] <seb_kuzminsky> thanks for your testing
[11:46:07] <jepler> lightly amended by putting back these lines
[11:46:07] <jepler> - // we need this for next time
[11:46:08] <jepler> - last = now;
[11:46:56] <seb_kuzminsky> yeah
[11:47:34] <seb_kuzminsky> the way the interpreter saves the parameter file is vulnerable to corruption, so i'm not surprised to hear ikcalB's bug report
[11:47:50] <seb_kuzminsky> but i'm also tempted to suggest the workaround of "dont pull power on a running machine"
[11:48:38] <seb_kuzminsky> safer replacement of the parameter file (and the tool file, probably) would be a good project for someone wanting to get into linuxcnc hacking
[11:48:43] <seb_kuzminsky> i think i'll make an issue for it
[11:55:15] <jepler> if (next_operation == RIGHT_BRACKET); /* nothing to do */
[11:55:27] <jepler> this line makes me uneasy, even though it appears to be correct
[11:56:03] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 db6276b 06linuxcnc 10configs/sim/axis/xhc-hb04/README 10lib/hallib/util_lib.tcl 10lib/hallib/xhc-hb04.tcl xhc-hb04.tcl support NONtrivkins world jogging JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=db6276b
[11:56:07] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #54: write the parameter file in a safer way 02https://github.com/LinuxCNC/linuxcnc/issues/54
[11:56:13] <seb_kuzminsky> dgarr is on fire, this is awesome
[12:01:57] <jepler> thoughts? https://emergent.unpythonic.net/files/sandbox/0001-interp-permit-exponential-format-numbers-inside-brac.patch
[12:02:06] <jepler> .. needs docs and tests
[12:02:23] <skunkworks_> pcw_home, I get 343us servo thread time on these hp's running its installed nic
[12:03:05] <pcw_home> which nic?
[12:05:34] <skunkworks_> 82579lm - using the e1000e kernel driver
[12:05:51] <skunkworks_> intel
[12:06:57] <pcw_home> my DC7800 gets about 225 usec max after about a week of normal desktop usahe
[12:07:06] <pcw_home> usage
[12:07:31] <pcw_home> did you do the intel nic ethtool trick?
[12:07:46] <kwallace> Hello, I have a tester that uses parallel ports (simple bit I/O). I got to thinking that it will be unlikely that the PC will be powered off when changing the boards being tested, so what should be the minimum features for hot plugging a parallel port?
[12:08:06] <cradek> jepler: that is clever, but part of me thinks adding features that are never or very rarely used is probably just best avoided
[12:09:09] <pcw_home> bus switches are nice for hot swapping
[12:09:15] <archivist> kwallace, connecting the ground & power first so static is dealt with
[12:09:26] <pcw_home> yeah and that
[12:10:24] <cradek> are you worried about your device or the parport? I think parports really don't have a problem with this
[12:12:35] <jepler> cradek: you're probably right
[12:12:52] <jepler> I was thinking about this because of that damn gscreen / gladevcp bug which this wouldn't fix anyway
[12:13:08] <jepler> (because you have to go add the brackets and 99.99999% of the time it's not an error if you forget them)
[12:13:21] <pcw_home> as archivist says, if you make sure theres a unbroken common ground between your device and the PC , you should be fine
[12:13:22] <cradek> actually I think it would...? I think it constructs an O-call which uses brakcets
[12:13:29] <jepler> oh maybe
[12:13:41] <jepler> I don't think those things *HAVE* to be O-calls, but in andy's case it was
[12:13:44] <jepler> or maybe they do, I dunno
[12:13:45] <cradek> oh
[12:13:47] * cradek shrugs
[12:13:55] <jepler> I think it's a general MDI constructor
[12:15:25] <kwallace> Currently, the test bed and PC are powered up in no particular order. The test GUI is invoked and a board is clamped on the test bed and tested. Once done, the board is changed and another test is run.
[12:16:12] <pcw_home> I have killed FPGA cards and parallel ports using cell phone chargers for FPGA 5V and hot plugging
[12:16:13] <pcw_home> (lack of common ground and high capacitance to line voltage in cell phone wall wart)
[12:16:37] <jepler> pcw_home: ugh I should be careful, I've done the same thing
[12:16:52] <jepler> I mean, the hot plugging and the USB 5V, not the toasting)
[12:17:29] <pcw_home> USB 5V is usually pretty safe
[12:18:02] <seb_kuzminsky> jepler: it makes me uneasy to accept different number syntax in different places
[12:18:06] <pcw_home> (V- is ground) even most laptop power supplies are grounded
[12:18:16] <seb_kuzminsky> especially when the syntax means something different and valid in some places
[12:20:22] <kwallace> I'm worried about an input becoming an output with one of the outputs winning the resulting fight. Also transients and I suppose static too. So far I'm planning to add a charge pump detector to control the test bed power, but I got to thinking I should also control an I/O buffer.
[12:21:25] <kwallace> This could be a far amount of work.
[12:24:44] <pcw_home> use a bus switch, they are designed for this (disconnnect all pins when off)
[12:25:42] <pcw_home> and make sure that there is always a common ground connected first
[12:26:18] <pcw_home> the bus switch avoids the buffer and signal direction issues
[12:27:09] <pcw_home> they are designed for hot swapping
[12:30:11] <kwallace> hmm... http://www.fairchildsemi.com/datasheets/FS/FSLV16211.pdf
[12:32:54] <kwallace> Thank you for the help guys.
[12:38:05] <skunkworks_> pcw_home, what is the incantation?
[12:39:33] <pcw_home> sudo ethtool -C ethN rx-usecs 0
[12:42:35] <pcw_home> kwallace: thats a 3.3V one (there are equivalent 5V ones)
[12:43:59] <kwallace> I also noticed some can do level shifting which sounds like it could be handy.
[12:45:26] <kwallace> I have four ports worth, port 0 and 1 on a 6i25, and two PC parports.
[13:00:48] <skunkworks_> pcw_home, 150us so far
[13:01:45] <skunkworks_> the linuxcnc whole package is pretty darn cool
[13:04:52] <skunkworks_> This is a 7i90
[13:05:14] <pcw_home> 92?
[13:05:39] <pcw_home> 80?
[13:05:47] <skunkworks_> sorry 7i92
[13:06:04] <skunkworks_> staying at about 500k clocks
[13:07:50] <mozmck> To make the rx-usecs happen on every boot, add: "hardware-irq-coalesce-rx-usecs 0" to your /etc/network/interfaces file in the section for the proper iface
[13:08:26] <skunkworks_> mozmck, Thanks! How is your project coming?
[13:08:35] <skunkworks_> project(s)
[13:08:40] <mozmck> auto eth0
[13:08:40] <mozmck> iface eth0 inet static
[13:08:40] <mozmck> address 10.10.10.1
[13:08:40] <mozmck> hardware-irq-coalesce-rx-usecs 0
[13:09:06] <mozmck> They are doing well so far. No end of work to do though it seems
[13:09:17] <skunkworks_> it certainly helped this..
[13:09:45] <jepler> that's a good tip. proofread that I added it to the docs correctly? https://emergent.unpythonic.net/files/sandbox/0001-hm2_eth-note-the-irq-coalesce-trick.patch
[13:09:47] <mozmck> I did find that on a marvel chipset that did not support that option, it made latency *really* bad to have that line in there.
[13:11:03] <jepler> hm there's no pleasing some NICs
[13:11:07] <mozmck> jepler: looks good, but we might mention somewhere that while it does no harm on some chipsets that don't support the option, on at least one marvel chipset it causes problems.
[13:11:24] <mozmck> That Marvel chipset works great without the line in there though.
[13:13:40] <jepler> updated: https://emergent.unpythonic.net/files/sandbox/0001-hm2_eth-note-the-irq-coalesce-trick.patch
[13:14:46] <mozmck> Looks good to me
[13:15:35] <mozmck> I believe the option worked fine with realtek chipsets I've tried (and I think pcw_home said the same thing) - even though they don't support the option.
[13:30:39] <KGB-linuxcnc> 03Jeff Epler 052.7 8c082ea 06linuxcnc 10docs/man/man9/hm2_eth.9 hm2_eth: note the irq-coalesce trick * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8c082ea
[16:59:16] <jepler> cradek or seb_kuzminsky: I see we now have a hostmot2-firmware repo on github. is it mirrored from glo to github like linuxcnc.git, or else what arrangements have we made?
[16:59:28] <jepler> I see that it doesn't have the same branches as glo so I guess it is not actively being mirrored
[17:16:26] <seb_kuzminsky> jepler: yeah i just pushed one branch by hand
[17:16:53] <seb_kuzminsky> it would be great if someone more responsible than me set up a pusher robot like for linuxcnc.git
[17:45:14] <andypugh> I wonder if it would be useful to have halcompile print a cheery “Sucess!” after compining and installing a custom comp? Unless you are a geek the output scrolling past is easy to mistake for an error report, and the final thing seen is a “cp” command which may be slightly subtle for some users.
[17:45:48] <andypugh> Or, as an alternative, it could spell “Success” correctly.
[18:02:26] <jepler> sure, if you think that would be good to add, go ahead
[18:26:13] <andypugh> Well, it’s easy to add the message for —install, but then I find myself wondering what the others should say :-)
[18:28:08] <JT-Shop> a sucess or even a success message would be good to see
[18:53:33] <andypugh> I wonder where \ is on this Mac keyboard in a Debian VM ?
[18:54:41] <andypugh> On a keyboard where the last letter on the ASDF row is “<“ where is “\” ?
[18:56:55] <andypugh> OK, so I tried all the keys. It isn’t there.
[20:04:38] <seb_kuzminsky> and if halcompile fails it pops up this gif: http://i.imgur.com/10lkUdy.gif
[20:41:25] <jepler> seb_kuzminsky: put it on the issue tracker I guess :-/
[20:49:09] <skunkworks> zlog