A customer asked for a parts total to count the number of parts on a bundle tag. We did not have this. What we did have was a total by item.

Details on the Macro can be found in the PMACROS document.

During the Records Test, Chain Test, one customer experienced an 0x800004FF task error, which indicates something is using up all of the CPU time.

The Error occured durring the Pass 2 test that verifies each of the record chains are valid. This test has code that checks the last time the test gave up time for other tasks to run but there was a change made to minimize the use of Rts_Sync_Acknowledge. This may be partially to blame for the Task Error.

The original test called Sync Wait every 15 seconds on a 30msec Sync Acknowledge. It did this after sending a message to the Peg Task to update the progress bar.

I have several concerns. Waiting 15 seconds to give up time is a significant amount of time to wait. In addition, at the time of the software edit, the sleep time was changed from a theoretical 30msec to 10msec. 10msec may not be a long enough time for the Peg Task to update the progress bar and anything else it needs to update after 15 seconds, to then be able to give up time for the lower priority tasks to run.

Two changes have been made. The time between sleeps has been changed to 5 seconds and the sleep time has been returned to the 30msec time that was originaly used for the Sync Acknowledge. If the original change caused the task error under extream conditions these two changes should prevent it from happening again or at least making it much less likely.

There is a chance that this customer still has another issue that created the extream test conditions but at least the Task error should be gone or at least less likely.

This task error happens if the resulting string of a Rts_Add_Hex_String exeeds 255 bytes, which is never supposed to happen. The only place this function is used is when adding the CRC to an Eclipse message response.

When investigating this error, I found that the response is tested a short time prior to this call and if it were anywhere close to causing this error, it was already being truncated. Something like an Interrupt would have to be modifying the response while we are building it.

We decided to double buffer the response from the buffer that is used by the RS485 interrupt to ensure that it is not the culpret.

In addition, just prior to calling the Rts_Add_Hex_String function we test again, just to be sure. If we find that it has been modified, we abandon the response to avoid generating the task error or sending a corrupted response.

The CtrlX drive expects the EtheerCAT Distributed Clock to be configured during Pre Op mode vs the other drives expecting it to be configured in Safe Op mode.

To preserve the best chance for older and newer drives to both operate, the EtherCat code was modified to support both.

The CtrlX drive is also more finicky about the synchronization of the clock. The code was modified to test the initial synchronization and use an offset to do the bulk adjustment. The code allows for up to 30 seconds for the clock to syncronize but with the initial bulk adjustment and a new test, in most cases it should only take a second or two.

The code was modified to handle a mixture of drives, those that want the DC to be configured in Pre Op and those who expect Safe Op.

The Min and Max Jitter values displayed in the diagnostic screen were filtered values, providing a false sens of the true min and max values.

Other diagnostic data is now being captured but only to the engineering serial output.

Sending the EtherCat cyclical frame needed to be seperated from the local encoder feedback capture and loop calculation. We needed to provide a larger safety margin for when to send the frame, while also trying our best to syncronize the EtherCat feedback capture with the XL local capture. More detail can be found in the Design_EC_Frame_Scheduling.md document in source control.

The symptoms of the issue were random negative, followed by immediate positive spikes in the CL Data feedback. This was caused by randomly getting old feedback for one sample that would catch up on the follwing sample.

While testing, we discovered an unexplained 100usec positive jitter that was eventaully tracked down to a 1024 byte mailbox size on the ctrlX. This is three times larger than the Indradrive. The full mailbox must be read. This equates to ~100usec on the bus vs ~25usec that the Indradrive has. While reserching, we implemented an errata fix on the NIC that was not provent to be required.

The new compiler for the XL200 code is producing less efficient code, causing 0xF0001 Task errors on dual die accelerators.

We believe this is due to inline math and other functions not being enabled.

Inline functions are now expanded inline for the application and the OS. They are not expanded inline in the PEG library due to an issue with how the libaries get built for the complex functions in PEG.