Maximilian H <[email protected]> wrote:
>1. Ntp/network is a good idea, since I do have this setup via cron to >check the time every 20 minutes. However, these ntp updates happen also >in the lab, and there I don't get any watchdog bite. Anyway I'll >disable >the ntp updates and see what happens. My thinking here is that it seems like your PC stops doing work (including petting the watchdog), but doesnt notice that it's stopped (or it would have emitted the "unexpected realtime delay" message). If an NTP server keeps having to tell your PC that more time has elapsed than the PC thinks, that would corroborate this theory. >4. Monitoring the epp communication with a digital scope would be an >option, I don't have one myself, but I know somebody how does. >Certainly >it would make sense to see if the communication really breaks down for >over 500ms. But I know nobody who owns a logic analyzer, so I can only >check 2 chan max. What pins on the ribbon cable are the most >interesting ? It would be sufficient to check the nDataStrobe line. If it stops wiggling for more than your servo period, something is wrong. >5. EMI certainly/unfortunately is a possibility. The ribbon cable from >the pc to the 7i43 is short, about 30cm, but who knows what kind of EMI >I do have in a 30y old mill. And of course the ribbon cable is not >shieled either. I tried running with the converter for the spindle >powered down, but that did not help either. You said this system was reliable for you on the bench, right? What's changed since then? You moved it and connected it to your mill, right? Any other changes (new cables, new power supply, etc)? If you disconnect it completely from your mill, does it become reliable again? >6. The 7i43's watchdog timeout I first had set to 5ms, then 100ms and >increased that value to a final value of 500ms. And still I got >watchdog >bites at a timeout of 500ms without any unexpected realtime delay >message. Of course, once the watchdog bites, I get following errors too >since the axes don't move anymore once the watchdog has bitten. You shouldnt ever have to change the watchdog timeout. A small number times the servo period should always work. >7. I will try to decrease vm swappiness from 60 (ubuntu's default) to >10. The machine has 4Gb ram of which only 3,5 are useable because of >the >32bit architecture. The linuxcnc pc never runs anything except >linuxcnc, >so it should never swap anyway. Swappiness shouldnt affect linuxcnc's realtime performance. And if it did, linuxcnc should notice and print "unexpected realtime delay". >8. External events. I could use the 7i43's hm2_7i43.0.watchdog.has_bit >pin as a trigger for halscope, but what other events should I monitor >in >halscope ? Halscope can only monitor a maximum of 8 channel, I believe. >Or does somebody have an working example of a streamer/halstreamer >setup >that I could copy. Anyway, what other values from hal space would be >interesting to debug this ? Ferror, cmd pos, fb pos, velocities, accel >for all axes, pwm values, the watchdog has-bit pin, the io_error pin, >and what else ? One theory Peter and i discussed is that your PC has noise on one of its EPP input data lines, specifically the LSB. This would manifest as a single-cycle-duration wiggle in the reported encoder location. Unfortunately the direction of the wiggle is unpredictable, so halscope can't easily trigger on it. An alternative way to see would be to enable the "raw" interface when you loadrt the hostmot2 driver, then re-read the watchdog register after it bites but before you reset it. If the watchdog report "not bit", then your problem is probably noise on the cable between the fpga and the pc. Although your report that the fpga pins become inputs when linuxcnc detects a watchdog bite indicates that the watchdog really *is* biting, that it's not a noise-induced false alarm... >9. Question. Since I don't have an io_error > 16 bit RW FALSE hm2_7i43.0.io_error >and the documentation at >http://linuxcnc.org/docs/html/man/man9/hm2_7i43.9.html tells me that >the >io_error should be set if I do have a broken epp communication, does >that mean that I can rule out EMI on the cable from the lpt port to the >7i43 ? No, the io_error bit only indicates an EPP protocol-level error. Noise can still corrupt the contents of the data transferred, and there's no way for EPP to tell. >10. I could buy a pcie lpt port and see if that helps. My guess is it wouldnt help. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
