Back
[13:10:19] <seb_kuzminsky> memleak: 3.4 is probably a good kernel to target for rtai, since it's a long-term-support kernel
[13:10:28] <seb_kuzminsky> so i'm glad to hear you have it working
[13:10:31] <seb_kuzminsky> i'll check it out
[13:14:39] <seb_kuzminsky> the milling machine crash i had with rtai 3.9.1-magma on linux 3.5.7 was strange, and repeatable
[13:15:09] <seb_kuzminsky> i use hostmot2 on all my machines, and both of the machines that displayed the problem use pci anyio cards
[13:15:33] <seb_kuzminsky> one's a servo machine (my bridgeport) that's been running great with our lucid rtai kernel for years
[13:16:07] <seb_kuzminsky> the other's a development machine with a 5i20 pci card and no real hardware connected, so i used our sample stepper config
[13:16:27] <seb_kuzminsky> on both machines, the feedback position reported by the anyio board to linuxcnc was moving
[13:16:40] <seb_kuzminsky> the servo machine tried to compensate and had a run-away, and crashed into the hard stop
[13:17:18] <seb_kuzminsky> the pretend stepper machine threw a following error, but the machine position reported on the axis dro kept moving (all 3 axes) at what looked like a constant rate
[13:17:21] <seb_kuzminsky> very strange
[13:17:30] <cradek> wow that is weird
[13:17:43] <seb_kuzminsky> basic pci i/o with the card is obviously working, or the firmware upload & initialization would not have worked
[13:17:50] <pcw_home> Shouldn't the servo machine shut down on a following error?
[13:18:00] <seb_kuzminsky> yes :-/
[13:19:11] <pcw_home> Without additional checks, thats the first line of defense against crazy servo behavior
[13:20:00] <cradek> first line is your limit switches in the estop chain - they sure aren't adequate (probably too far out) it seems
[13:20:48] <seb_kuzminsky> i still need to check my servo braking resistors on that machine
[13:21:06] <pcw_home> I think of that as second since all kinds of havoc can come from a full range unplanned move
[13:21:28] <cradek> iirc it shorts the motors with those contactors in the bottom of the cabinet
[13:22:22] <pcw_home> so it shorts the motor after the physical limits?
[13:22:33] <cradek> no, I think it does it anytime during estop
[13:22:39] <seb_kuzminsky> pcw_home: after estop, and the limits cause estop
[13:22:55] <cradek> yes I think that's right
[13:23:04] <pcw_home> OK
[13:23:13] <seb_kuzminsky> i'm second-guessing my memory of the event now
[13:23:36] <pcw_home> But not enough deccel to prevent a mechanical crash?
[13:23:49] <seb_kuzminsky> i remember getting the new rtai up on that machine, but something was preventing me from starting it up
[13:24:10] <seb_kuzminsky> i'm wondering if i was dumb enough to unhook linuxcnc from the estop chain and starting everything
[13:24:14] <seb_kuzminsky> gods i hope not
[13:24:40] <seb_kuzminsky> i'll debug more on the bench and report back...
[13:24:51] <cradek> eh, if you make each mistake just once you're doing fine
[13:25:28] <seb_kuzminsky> pcw_home: yeah i think that's right
[13:25:43] <seb_kuzminsky> limit-triggered estop does not decelerate the machine fast enough to prevent a crash currently, apparently
[13:25:49] <cradek> those contactors could be dirty or just broken. you'd never notice it unless you looked hard.
[13:25:51] <seb_kuzminsky> which seems like a terrible mis-configuration
[13:26:06] <pcw_home> Does seem like following error would catch seriously bad encoder data though
[13:26:54] <seb_kuzminsky> sure, but if i somehow borked my estop chain it wouldnt help if linuxcnc noticed the problem, it'd be helpless to stop the impending crash
[13:27:59] <cradek> also if it isn't writing out the right things to the hardware...
[13:28:09] <seb_kuzminsky> right, that could be
[13:28:10] <cradek> all outputs on, all dacs on FULL THROTTLE
[13:28:16] <pcw_home> I though normally the drives were disabled by a following error (no estop involvement)
[13:28:17] <seb_kuzminsky> no
[13:28:32] <seb_kuzminsky> if all outputs are on, the /enable line to the 7i33 will disable dac output
[13:29:23] <pcw_home> Yes bad data migh cause a crash (but watchdog would need good data)
[13:29:48] <cradek> but I think the watchdog isn't enabled until communication is already working right?
[13:30:28] <pcw_home> Probably the driver should check the watchdog every startup
[13:30:49] <seb_kuzminsky> the watchdog comes on at the first invocation of pet_watchdog, iirc
[13:30:59] <seb_kuzminsky> so as soon as the realtime threads are started
[13:43:39] <memleak> seb_kuzminsky, I try to support LTS kernels as much as possible
[13:44:02] <memleak> it's easy to do too, I hardly have to do anything after the first bump.
[13:44:46] <memleak> The most challenging thing IMO is adding support to kernels that were never in the RTAI tree, such as 3.4
[13:47:45] <jepler> the "pronteface" user interface for 3d printers doesn't have an obvious keyboard or gui shortcut for "geez, stop moving now". You can flick the power switch or click the MDI field and enter M112 (Emergency Stop)
[13:47:54] <jepler> "pronterface", that is
[14:11:50] <jepler> huh a DLP 3D printer for only $1500
https://www.tindie.com/products/Ron/sedgwick-3d-dlp-printer/
[14:12:14] <jepler> vat is 75x75x120mm so I suppose printable volume is something like 70x70x100. not huge by any means
[14:12:57] <jepler> resin $75 / 1L, and filling the "big vat" would take about a half liter..
[14:13:04] <jepler> maybe next year
[15:41:03] <memleak> gabewillen, hello!
[15:41:19] <memleak> you tried to contact me this morning when i was still asleep, whats up?
[16:55:35] <mhaberler> jepler: we need to book a timeslot of your attention - we have an intermediate merge result looking promising, but there were some open questions about the deps and Makefile changes and runtests mods; I guess we'll have something where we ask you to look at, plus a laundrylist, by tomorrrow evening CET
[17:41:53] <andypugh> seb_kuzminsky: Was this crash with a 64 bit kernel? Is the problem possibly the one I spotted with the resolver code where internal promotion of 32 bit registers to 64 bit accumulators was broken?
[17:42:24] <andypugh> (Incidentally a horrible bug that I need to fix, but first need to build a 64-bit system to check it on)
[17:48:57] <seb_kuzminsky> andypugh: no, this was a 32-bit system
[18:17:09] <andypugh> OK. I don't know if that is good news or bad news
[22:06:05] <CaptHindsight> jepler: I'll send you a gallon of photopolymer to play with
[22:06:42] <CaptHindsight> you can build a top down projection DLP printer like that yourself for much less
[22:07:18] <CaptHindsight> used DLP + a Z axis and vat
[22:29:59] <jepler> CaptHindsight: thanks for the offer, I don't need the additional project right now though
[22:35:59] <CaptHindsight> jepler: ping me about it when you have the time and desire