Random read errors on Mesa 7i92

This could be caused by a dropped packet so it may be a hardware error on the host PC or the 7I92
it could also be EMI related especially if you only see errors when noise sources like a VFD are on

Assuming its a dropped packet problem related to noise, i would first try re-routing the Ethernet cable
away from noise sources (power and motor wires) and perhaps using shielded cat5

Another option is to try jeplers experimental eth-packet-loss branch of linuxcnc that copes better with dropped packets

Another quick way to bisect the problem is try another PC

EMI interference is something that I had considered before. I don't have a VFD, and I didn't think I had a source of high frequency interference, but I though I'd look into it anyway.

I didn't know they made shielded Ethernet cables. I don't have any, so I grabbed another regular cable and made the connection. I hung the wire from the ceiling so it was not around any potential sources of EMI.

First test - 8 hours without an error.
Second test - 13 hours without an error. Went to be for night, and in morning had an error.

This is very promising, and is the longest run times I've gotten yet. I've ordered a shielded cable to try out. Is there anything special I should do around the 7i92 board itself?

Here's a picture of my control box. The Mesa card is in the lower right corner. Other components are a switching power supply for the steppers, a 24VDC power supply, a 24VDC-5VDC buck, four stepper drivers, and two breakout boards. I would think that the switching power supply is OK since it's in a separate metal enclosure. The buck is not enclosed, and maybe it could be a problem. The computer is mounted on the back of a touchscreen, and it's possible that's making some EMI.

The old ethernet cable ran with some other cables. The only thing with any AC is the signal from the spindle encoder.

image missing http://i68.tinypic.com/16jfuky.jpg

Normally Ethernet has very good noise immunity so I still am suspicious that something else is going on
the shielded cable is simple so worth a try though

( also unfortunately random failures are well... random so you might just be having a good day)

I would till still try the packet loss branch or a different PC at least as a test

Are those BOB's Chinese made 5 axis ones? I would highly recommend changing them, especially if you are using inputs on them.
Or you will have to add 470 ohm pull up resistors to all inputs and test if whatever is connected to them can pull them down as necessary and invert them in hal as needed. They are very susceptible to interference, all kinds of it.
I have to agree with PCW, it sure looks like interference from something, not just RF, all bigger equipment power wise will cause magnetic fields on supply wires, so using a shielded cable should be first order of business.
Regards,
Tom

I've had some success!

I ordered a new shielded ethernet cable. When I installed it, I found that my vent fan had shorted out earlier, and taken down the 24V and 5V power supplies, which killed power to the Mesa card. I think that this caused the read error that I mentioned a few posts back.

The new ethernet cable (and also the commercially made regular cable that I used earlier) have eliminated the

hm2/hm2_7i92.0: error finishing read! iter = xxxxxxxxxx

problems that I was experiencing. The old cable I was using was a home made cable that was about 25 years old, and I think that it had a weak connection somewhere that was causing the dropped packets.

I'm still getting the

Unexpected realtime delay on task 0 This message will only display once per session Run the latency test and resolve before continuing

message.

As I mentioned in an earlier post, I'm getting occasional delays of 45-55,000, but in general my latency is fairly low. My understanding is that these are acceptable for the USB Mesa card. I'm not sure what level of latency triggers the realtime delay message, but perhaps it's set at 50,000 or so, and I should just ignore the message.

The latency numbers in the latency test are really just dispatch latency
(the test doesn't actually do anything like allocate memory or perform I/O, things that can have their own latencies)

What is likely happening is that you are running out of time on the servo thread
to check this, watch

servo-thread.tmax

This is the maximum number of CPU clocks that the servo thread took to complete
If its getting close to servo_thread_period*CPU_Clock_Speed, you will get real time delay errors
The solution is to either improve the latency or raise the servo thread period