dmoore
Senior elf
In working with Ed on another issue, he provided me the description on what the slave stats in the webpage on the ECG8 mean. This is for version 1.1.0 I think...
On the status webpage:
!!! – means there is at least one error in the stats for this slave
On slave stats webpage:
Overrun – each slave is double buffered. The master tried to send data when BOTH were already full
Runt/big, short, long – communications (spi) errors from master to slave – I’ve never seen one except when I was first writing/testing the firmware – it would indicate a hardware/firmware error
Unconfig – a slave could be reset by a hardware glitch and not have any config data (ren/dmx? Speed?) and yet the master is sending it data. again never seen in real life. I’ve forced one by reprogramming a slave while the system was receiving data. a reboot of unit get’s everyone back in synch
But there is yet another type of overrun that I don’t report (cause I don’t see them). The firmware is doing its best to process ALL packets it receives. The Ethernet co-processor has a limited amount of ram (20k?) to buffer received packets. If packets arrive and there is no room the Ethernet co-processor has to drop it on the floor. The way to see if that is happening is to get packet sent counts from the plugin and compare it to packet received counts in the ECG.
All of these are diagnostic tools to track down problems ‘on the bench’. Once working you shouldn’t see any errors in a production environment.
----------------------------------------
On a side note - some may have heard that LSP didn't work properly with the full 8 universes on an ECG8. This was the case in 1.7. According to the LSP bug report, this problem has been resolved in the latest 1.8 release that will be going public soon.
On the status webpage:
!!! – means there is at least one error in the stats for this slave
On slave stats webpage:
Overrun – each slave is double buffered. The master tried to send data when BOTH were already full
Runt/big, short, long – communications (spi) errors from master to slave – I’ve never seen one except when I was first writing/testing the firmware – it would indicate a hardware/firmware error
Unconfig – a slave could be reset by a hardware glitch and not have any config data (ren/dmx? Speed?) and yet the master is sending it data. again never seen in real life. I’ve forced one by reprogramming a slave while the system was receiving data. a reboot of unit get’s everyone back in synch
But there is yet another type of overrun that I don’t report (cause I don’t see them). The firmware is doing its best to process ALL packets it receives. The Ethernet co-processor has a limited amount of ram (20k?) to buffer received packets. If packets arrive and there is no room the Ethernet co-processor has to drop it on the floor. The way to see if that is happening is to get packet sent counts from the plugin and compare it to packet received counts in the ECG.
All of these are diagnostic tools to track down problems ‘on the bench’. Once working you shouldn’t see any errors in a production environment.
----------------------------------------
On a side note - some may have heard that LSP didn't work properly with the full 8 universes on an ECG8. This was the case in 1.7. According to the LSP bug report, this problem has been resolved in the latest 1.8 release that will be going public soon.
