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

[01:07:26] <pink_vampire> hi
[01:08:05] <pink_vampire> i have a question for the developers
[01:08:57] <pink_vampire> Is there a way to send a signal to pin9 in the lpt each time that any of the the axis move?
[01:10:40] <pink_vampire> any of the the drivers get pulses, I need to get 1 logic in pin 9, when non of the drivers get pulses pin 9 go to 0 logic.
[01:11:08] <pink_vampire> Something like that can be done with linux cnc??
[01:55:24] <KGB-linuxcnc> 03Sebastian Kuzminsky 05joints_axes13 5e6cc89 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt docs: fix a typo in Updating LinuxCNC * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5e6cc89
[01:55:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 05joints_axes13 62d3e41 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt docs: fixup asciidoc markup in Updating LinuxCNC * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=62d3e41
[01:55:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 05joints_axes13 9b231b8 06linuxcnc 10docs/man/man9/kins.9 docs: update kins.9 manpage trivkins with some gantry info * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9b231b8
[01:56:11] <seb_kuzminsky> ja13 drives the big gantry machine at the hackspace so much better than 2.7 does
[01:56:22] <seb_kuzminsky> soft limits, incremental jogging, mm-mmm
[01:57:23] <seb_kuzminsky> pink_vampire: there's probably a couple of ways to do that
[01:57:58] <seb_kuzminsky> if you're using steppers with software step generation you could OR all the step outputs together and send the result to pin 9
[02:00:23] <pink_vampire> seb_kuzminsky: I need it and "move/dont move" (like on off)
[04:57:13] <pink_vampire> seb_kuzminsky: I've dried to do it with hal and the hal intro, but it beyond me
[06:21:02] <jthornton> this combo looks good http://gnipsel.com/images/emc/ASRock%20H97M%20Pro4%20-44592.png
[07:42:43] <jthornton> sudo apt-get install mesaflash returns E: Unable to locate package mesaflash
[07:42:50] <jthornton> what am I missing?
[07:43:51] <skunkworks> what os?
[07:44:28] <jthornton> linuxmint 17.3 with rtai
[07:47:19] <skunkworks> I would guess your missing the correct apt source. I am assumming there isn't one for linuxmint
[07:47:45] <skunkworks> you would grab the deb from linuxcnc.org.. I don't know where it is yet..
[07:47:54] <jthornton> I have it somehow on two other mint pcs
[07:48:14] <jthornton> just found this googling deb http://linuxcnc.org wheezy base
[08:02:48] <skunkworks> jepler, this morning I got this
[08:02:49] <skunkworks> http://pastebin.com/1rWahXph
[08:03:04] <skunkworks> (the following errors is me trying to run a program)
[08:04:09] <jepler> hm2/hm2_7i92.0: error finishing read! iter=148384927)
[08:04:40] <jepler> I wonder why that got printed twice
[08:04:48] <jepler> I wonder why nobody has fixed that stray ")"
[08:05:17] <jepler> anyway, before the branch that's what you'd get with a single failed read. once in this state, there's a HAL pin you have to reset to resume trying to communicate.
[08:05:32] <skunkworks> ok
[08:05:43] <jepler> so after this has happened, the following error is not unexpected -- the motors shouldn't actually be turning
[08:05:52] <jepler> this is pin hm2_7i92.io_error or something like that
[08:06:28] <jepler> anyway, with my branch this should only occur after a "large number" of errors communicating with the board in a cluster
[08:07:34] <jepler> .. but I assume yo've run this setup for much more than 140 million base periods (1.7 days at 1ms) in which case it's a surprising result
[08:08:50] <skunkworks> I know it has run for a week..
[08:09:30] <skunkworks> no realtime error.
[08:09:44] <skunkworks> which is what I would have expected.
[08:10:52] <skunkworks> heh
[08:10:54] <skunkworks> So many matsuuras out there with arcane yasnac controls. Like it.
[08:10:55] <skunkworks> When is your conversion kit going on the market ?
[08:19:01] <skunkworks> pcw_home, could the ethernet boards run poe? ;)
[08:27:51] <jepler> my branch lowers the maximum time it will wait for a packet to get back from "way enough to cause a realtime error while waiting" to 60% of the servo-thread period
[08:28:11] <jepler> but even if there's an occasional packet that takes between 60% and 100% of servo-thread period to get returned, you wouldn't expect a cluster of them
[08:50:22] <skunkworks> The servo thread tmax is 794us
[08:50:42] <skunkworks> if there was a bunch in a row at that delay?
[09:55:08] <pcw_home> skunkworks: on hm2_eth before jeplers patch, a "error finishing read" really means a lost packet (I think it waits 200 ms or something like that)
[09:56:04] <pcw_home> by which time of course everything's bolluxed up
[10:01:03] <pcw_home> I have a test setup with the read timeout threshold set so theres a timeout 100s of times a day and its been fine
[10:01:04] <pcw_home> (still doesn't work with sserial however)
[10:02:58] <pcw_home> is it possible the 7I92 lost power?
[10:04:36] <pcw_home> I should probably put a "cold start cookie" somewhere so this can be checked
[10:27:59] <skunkworks> hmm - I don't know - it is running off a wall wart..
[10:28:03] <skunkworks> I could try a different one
[10:28:18] <skunkworks> or - now I could use usb. let me try that.
[10:45:16] <pcw_home> unfortunately with the stock error handling, you cannot tell what happened
[11:21:11] <jepler> I should also try leaving mine running for a few hundred hours
[11:22:09] <jepler> I am dreading trying to figure out how to deal with lost packets when it comes to the serial devices.
[11:24:00] <pcw_home> I think the easiest thing (for almost all modules) is to not process the rx data (or use the stale data)
[11:28:27] <pcw_home> (when a packet is lost, or times out)
[11:36:08] <pcw_home> I think the problem sserial is that the RX data is all Zeros if timed-out which causes havoc in the control register data parsing
[11:41:53] <jepler> I still have the sserial boards so I can test this
[12:03:23] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/trt_doc_test_v2 8febd0b 06linuxcnc 10docs/src/motion/5-axis-kinematics.txt 5-axis-kinematics.txt minor markup fixes JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8febd0b
[13:59:04] <skunkworks> zlog
[16:37:14] <jepler> somebody should write an EPP firmware for one of the db25/hd26 mesa cards so my stubborn friend can use it to get his pluto working again.
[16:37:26] <jepler> how hard could it be
[17:15:02] <PCW> I've thought about it, you could make it show up as a standard parallel port so no special driver support was needed
[17:16:59] <PCW> or simpler still you could make a hostmot2 module (but it would need driver support for the EPP passthrough)
[19:05:22] <JT-JA13> PCW: any 7i73's in stock yet?
[19:20:35] <PCW> We will likely get them next week
[21:21:45] <skunksleep> Rigid tapping works in air... (Using the gear tooth sensors)
[21:23:53] <skunksleep> Ran into the 'too many turns before stopping' issue at 2000rpm... ;)
[21:25:36] <skunksleep> Certainly puts linuxcnc in an odd spot