The newest release of the firmware for the ECG (DMXRen8 and DR4) is now available in the download area on www.j1sys.com
This release includes three major updates:
1) Hash Table Multicast Filtering - the software now takes advantage of a hash table filter that is available in the hardware of the ENC624 Ethernet chip. This is transparent to the user and just helps reduce the processor load on the master processor in a heavily loaded multiple ECG environment. We still recommend Unicast as the most efficient transmission method and the ECG is still not fully compliant with the multicast protocol so you have to be sure your multicast aware switches are set for repeating all multicast packets out all connections.
2) User Configuration Of Keep-Alive Operation - there is a new set of parameters available on a per-slave basis on the slave configuration screen to enable/disable keep-alives, set the interval, and the clear and repeat interval count.
3) Last In Overrides Pending (LIOP) - each slave has a FIFO buffer that allows for multiple universes to be queued up for transmission by the slave. This can add some latency and is not necessarily appropriate when receiving a burst of packets all destined to the same universe. The current (non-LIOP) mode would queue up 4+ universe packets and then discard any additional overruns. Then the transmitter might take approximately 100ms to transmit the queued packets. LIOP mode examines the FIFO buffers and replaces (overrides) the queued data for the targeted universe thus keeping the queue to a minimum and always transmitting the most recent data available when the current buffer is depleted. The slave still queues multiple packets for multiple universes where needed for hyperDMX functionality.
The Master/Slave software should be updated to the same revision level. The Master should be flashed and then each Slave should be flashed and then the unit powered off to reboot. Be sure to read the information on the firmware download page about what software combinations are needed to program each processor.
If problems arise downgrade both master and slaves back to the same revision level. With all the new parameters the configuration memory had to be reorganized and all configuration data will be lost when upgrading or downgrading the software so be sure to document your current settings before proceeding. So your v1.3.1 Master should show all v1.3.1 Slaves as shown below:
The configuration screen has been changed to include all the new parameters:
Under protocol parameters (equivalent to the old configuration screen) we have added a new check box to enable the LIOP option. You can enable/disable it on a per slave basis.
A new section has been added to the configuration screen to configure the keep-alive parameters. On a per slave basis you can:
1) enable/disable keep-alive
2) enable/disable startup clear universe option
3) define the keep-alive interval in milliseconds
4) define an interval count since the last packet has been received at which the slave should clear (zero) the keep-alive buffer to then send all zeroed packets for the duration of the total keep-alive period. if set to 0 the buffer will not be cleared.
5) define an interval count that will terminate the keep-alive. if set to 0 the keep-alive will never terminate and will continue transmission until the unit is powered off.
6) define the initial universe size to be used for the startup cleared keep-alive if enabled. this is only used during startup keep-alive. The actual received universe size is used for all subsequent keep-alives.
The receipt of any new packet will take precedence over the pending keep-alive and reset the counters to start a new interval and a new count of interval to determine whether clear count (if any) has been reached or if the keep-alive should be terminated.
The example above has set all of the parameters to a conservative default. All keep-alives are enabled, all slaves will send zeroed universes on power-up/reboot to clear any outstanding lighting commands, the keep-alive interval is set to 500ms, the keep-alive buffer will be cleared after 10 intervals (5 seconds), the keep-alive will stop after 20 intervals (10 seconds), and for all Renard slaves the initial universe size is set to 128 slots while the DMX universe is set to 512 slots.
You can play with any of these parameters to tune the keep-alive to your particular needs. If you reduce the interval to less than the time it takes to transmit your universe it will, in essence, start keep-alives immediately UNLESS another packet has arrived. But since this may then take approximately 25ms to complete you will be adding a latency that we believe will be detrimental to the response time of the system. If you feel you need a quicker keep-alive than our 500ms example we would suggest never going less than 2.5 times your transmission period.
The startup keep-alive is enabled independently of the overall keep-alive but uses the Total Count to limit the zeros or to keep transmitting indefinitely if the Total Count is zero.
You might try the example values, power-up your unit, examine the stats and watch the lights to see the 20 zeroed keep-alive transmissions that occur and then the unit will go into idle state. Then transmit some data and you will see the 10 keep-alive transmissions with the last data received followed by the 10 keep-alive transmissions with zeroed data to clear your lights for a total of 20 additional keep-alive transmissions.
Please give it a try and let me know of any helps on lag times, better control on keep-alives, or any problems.
Ed
This release includes three major updates:
1) Hash Table Multicast Filtering - the software now takes advantage of a hash table filter that is available in the hardware of the ENC624 Ethernet chip. This is transparent to the user and just helps reduce the processor load on the master processor in a heavily loaded multiple ECG environment. We still recommend Unicast as the most efficient transmission method and the ECG is still not fully compliant with the multicast protocol so you have to be sure your multicast aware switches are set for repeating all multicast packets out all connections.
2) User Configuration Of Keep-Alive Operation - there is a new set of parameters available on a per-slave basis on the slave configuration screen to enable/disable keep-alives, set the interval, and the clear and repeat interval count.
3) Last In Overrides Pending (LIOP) - each slave has a FIFO buffer that allows for multiple universes to be queued up for transmission by the slave. This can add some latency and is not necessarily appropriate when receiving a burst of packets all destined to the same universe. The current (non-LIOP) mode would queue up 4+ universe packets and then discard any additional overruns. Then the transmitter might take approximately 100ms to transmit the queued packets. LIOP mode examines the FIFO buffers and replaces (overrides) the queued data for the targeted universe thus keeping the queue to a minimum and always transmitting the most recent data available when the current buffer is depleted. The slave still queues multiple packets for multiple universes where needed for hyperDMX functionality.
The Master/Slave software should be updated to the same revision level. The Master should be flashed and then each Slave should be flashed and then the unit powered off to reboot. Be sure to read the information on the firmware download page about what software combinations are needed to program each processor.
If problems arise downgrade both master and slaves back to the same revision level. With all the new parameters the configuration memory had to be reorganized and all configuration data will be lost when upgrading or downgrading the software so be sure to document your current settings before proceeding. So your v1.3.1 Master should show all v1.3.1 Slaves as shown below:
The configuration screen has been changed to include all the new parameters:
Under protocol parameters (equivalent to the old configuration screen) we have added a new check box to enable the LIOP option. You can enable/disable it on a per slave basis.
A new section has been added to the configuration screen to configure the keep-alive parameters. On a per slave basis you can:
1) enable/disable keep-alive
2) enable/disable startup clear universe option
3) define the keep-alive interval in milliseconds
4) define an interval count since the last packet has been received at which the slave should clear (zero) the keep-alive buffer to then send all zeroed packets for the duration of the total keep-alive period. if set to 0 the buffer will not be cleared.
5) define an interval count that will terminate the keep-alive. if set to 0 the keep-alive will never terminate and will continue transmission until the unit is powered off.
6) define the initial universe size to be used for the startup cleared keep-alive if enabled. this is only used during startup keep-alive. The actual received universe size is used for all subsequent keep-alives.
The receipt of any new packet will take precedence over the pending keep-alive and reset the counters to start a new interval and a new count of interval to determine whether clear count (if any) has been reached or if the keep-alive should be terminated.
The example above has set all of the parameters to a conservative default. All keep-alives are enabled, all slaves will send zeroed universes on power-up/reboot to clear any outstanding lighting commands, the keep-alive interval is set to 500ms, the keep-alive buffer will be cleared after 10 intervals (5 seconds), the keep-alive will stop after 20 intervals (10 seconds), and for all Renard slaves the initial universe size is set to 128 slots while the DMX universe is set to 512 slots.
You can play with any of these parameters to tune the keep-alive to your particular needs. If you reduce the interval to less than the time it takes to transmit your universe it will, in essence, start keep-alives immediately UNLESS another packet has arrived. But since this may then take approximately 25ms to complete you will be adding a latency that we believe will be detrimental to the response time of the system. If you feel you need a quicker keep-alive than our 500ms example we would suggest never going less than 2.5 times your transmission period.
The startup keep-alive is enabled independently of the overall keep-alive but uses the Total Count to limit the zeros or to keep transmitting indefinitely if the Total Count is zero.
You might try the example values, power-up your unit, examine the stats and watch the lights to see the 20 zeroed keep-alive transmissions that occur and then the unit will go into idle state. Then transmit some data and you will see the 10 keep-alive transmissions with the last data received followed by the 10 keep-alive transmissions with zeroed data to clear your lights for a total of 20 additional keep-alive transmissions.
Please give it a try and let me know of any helps on lag times, better control on keep-alives, or any problems.
Ed
