Back
[11:23:19] <mozmck> Is there a way using hal tcl to see if a loadusr command fails? I want to test and give some useful feedback instead of just crashing.
[12:09:37] <seb_kuzminsky> mozmck: i dont know, but i've wished for a feature like that too, except in python instead of tcl ;-)
[12:31:01] <pcw_home> I guess I should add a netmask/broadcast handling to the hm2-eth remotes
[12:33:51] <pcw_home> (to make a script that finds them easier)
[12:40:16] <mozmck> seb_kuzminsky: I don't know python a whole lot better than tcl so far. If I can test for the existence of the command before I try loadusr that would work, but I don't know how to do that in tcl
[12:40:56] <mozmck> pcw_home: that would nice.
[12:58:20] <mozmck> zlog
[12:58:45] <mozmck> pcw_home: I was thinking of just setting each eth interface to 10.10.10.1 and pinging 10.10.10.10
[13:02:46] <pcw_home> Yeah that should work in most cases
[13:03:55] <pcw_home> but they cards really should respond to a ping or UDP broadcast
[13:04:40] <mozmck> How would you do a UDP broadcast? Does the eth iface have to be set to the right IP first?
[13:04:54] <pcw_home> just need to add a netmask EEPROM entry (looks like I left space for one)
[13:05:23] <mozmck> I mean how would I do one from a script?
[13:08:05] <pcw_home> to be less disruptive you could send a broadcast UDP read request (maybe read cookie) from each active interface
[13:14:29] <pcw_home> for a script, the python socket interface support broadcasts
[13:15:00] <pcw_home> presumably need to be root
[13:32:13] <JT-Shop> WOW! cutting with 2.7 on the plasma and it looks so clean you think it was laser
[13:39:22] <skunkworks> JT-Shop: awesome!
[13:40:56] <skunkworks> the new tp is pretty awesome
[13:44:38] <JT-Shop> yea, the plasma has never cut that clean with almost 0 dross
[13:44:49] <JT-Shop> I'm stoked!
[13:52:55] <pcw_home> more constant velocity makes the difference?
[13:59:37] <JT-Shop> yea
[14:04:56] <JT-Shop> well velocity and arc voltage
[14:22:50] <skunkworks> pictures!
[14:30:55] <pcw_home> I suspect a lot of people will be pleasantly surprised by the new TP in 2.7
[14:34:00] <Tom_itx> can't wait to get this thing back together now
[14:34:05] <tinkerer> jepler: do you mean my humble self? :)
[14:36:53] <tinkerer> http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2015-05-08.html#21:14:56
[16:50:38] <tinkerer> cradek: do you have more infos about this issue?
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2015-05-08.html#20:55:47
[16:53:21] <tinkerer> setup, lcnc version aso...
[17:02:28] <cradek> sure
[17:03:06] <cradek> it's a sun1888 card, linuxcnc is the released 2.6.7 on wheezy/rtai
[17:03:27] <cradek> works on my old P3 with built-in motherboard parallel port
[17:03:39] <cradek> I'm trying to move to a newer pc, so I ended up with a pci parport
[17:04:09] <cradek> it's now unhooked but if you want to work on it, I'll pull it back off the shelf
[17:05:04] <cradek> the kernel identifies the parport and sees its two io regions, shown in lspci, as lo and hi addrs (parport_pc shows this if you boot with debug on the kernel command line)
[17:05:30] <cradek> so I was trying loadrt pluto_servo ioaddr=0, as well as other combinations of specifying ioaddr and ioaddr_hi directly
[17:06:50] <tinkerer> are you sure that the firmware is loaded properly
[17:07:24] <cradek> no, I only have the error message from the pluto_servo
[17:08:18] <tinkerer> a method to test this is to load a led blinking firmware
[17:10:50] <cradek> does pluto_servo or pluto_step have any default behavior I could see somehow?
[17:11:21] <tinkerer> changing the 1st line in the Submakefile to:
[17:11:22] <tinkerer> hal/drivers/pluto_servo_rbf.h: hal/drivers/pluto_servo_firmware/LEDblink.rbf hal/drivers/rbf2h.py
[17:11:22] <tinkerer> and deleting the pluto_servo_rbf.h then re-making the src
[17:11:56] <tinkerer> I can send you the LEDblink.rbf
[17:12:17] <tinkerer> to you
[17:14:56] <cradek> cool, you are right, that would cut the problem space in half
[17:15:19] <cradek> I will not be able to work on it until tomorrow though, unfortunately, lots of stuff going on tonight
[17:15:27] <cradek> will you be around tomorrow?
[17:15:35] <tinkerer> quarter... ;)
[17:15:45] <cradek> you can put the firmware online somewhere, or send it to me, chris@timeguy.com
[17:15:51] <cradek> I don't understand quarter
[17:16:38] <tinkerer> or third
[17:16:50] <jepler> tinkerer: must be. hi.
[17:17:02] <tinkerer> it was a joke
[17:17:13] <tinkerer> jepler: hi
[17:17:56] <cradek> I have to run, thank you tinkerer, email me please
[17:21:03] <tinkerer> on the way. cu.
[19:28:27] <dgarr> mozmck: a loadusr_substitute might work for you:
http://www.panix.com/~dgarrett/stuff/loadusr_substitute
[19:53:07] <skunkworks> the mazak moves about .005 randomly.. don't know if it is mechanical or electrical. leaning towards mecanical.
[19:59:58] <pcw_home> motor shaft bounces around randomly?
[20:06:08] <mozmck> dgarr: thanks, I'll try that. I was thinking of using something like exec which <my_program> to see if it existed in the path.
[20:16:06] <dgarr> yes, exec which should work too
[20:34:47] <AndChat|144384> pcw_home: no..
[20:36:42] <pcw_home> DRO right but physical position is off?
[20:36:56] <skunksleep> Yes.
[20:38:05] <skunksleep> Still off after rehoming. (Seems to home to an index)
[21:02:46] <skunkworks> They may be resolvers..