Version 2.2 Patch 1 - PV750 with All 2.2 Patch 1 updates (including bootloader).

Using 11-bit CAN in big endian

I have written a configuration that sends multiple 8 byte messages all with the same identifier. The messages need to be sent as fast as possible. I have state machines that first calculate the high 4 bytes and then the low 4 bytes. Immediately following I send the FFCAN message and then continue to calculate the high and low sections again. When run on the display, all of the calculation events are completed and then all of the FFCAN sends take place. This results in all of the CAN messages being the exact same (whatever the last calculation was), rather than sending the CAN message after each calculation. An example below:

CCM-> FireEvent (Calculate High 4.1)
CCM-> FireEvent (Calculate Low 4.1)
CANOpen -> Tx Std Free Form (FFCAN Test Message)
CCM-> FireEvent (Calculate High 4.2)
CCM-> FireEvent (Calculate Low 4.2)
CANOpen -> Tx Std Free Form (FFCAN Test Message)
CCM-> FireEvent (Calculate High 4.3)
CCM-> FireEvent (Calculate Low 4.3)
CANOpen -> Tx Std Free Form (FFCAN Test Message)

When executed, all 3 transmitted messages are with the data calculated in the last calculation events (4.3 in this case). I have actually done this with over 60 calculations amd messages and it is always the final calculation that is sent.

Hello mbowdich

Thank you for bringing this to our attention. I will enter a bug for this issue. It seems like it has to do with the priority of the events. The higher priority events are executed first.

The work around is to break up your state into several states separated by a timer.
For example:
STATE 1
CCM-> FireEvent (Calculate High 4.1)
CCM-> FireEvent (Calculate Low 4.1)
CANOpen -> Tx Std Free Form (FFCAN Test Message)

1ms Timer

STATE 2
CCM-> FireEvent (Calculate High 4.2)
CCM-> FireEvent (Calculate Low 4.2)
CANOpen -> Tx Std Free Form (FFCAN Test Message)

1ms Timer

STATE 3
CCM-> FireEvent (Calculate High 4.3)
CCM-> FireEvent (Calculate Low 4.3)
CANOpen -> Tx Std Free Form (FFCAN Test Message)

I attached a config for the PV750 that shows an example with a free form CAN message. The first state calulates the byte to 1 and then sends. The second state calulates the byte to 2 and then sends. The third state calculates the byte to 3 and then sends. There is a 1ms timer between each state.

Brad Seidl
Test Engineer
FW Murphy

I already tried that, but the number of messages being sent makes this size state machine too cumbersome. For an interim solution, I made up multiple FFCAN messages with the same ID but different names and am sending them with separate variables. It appears to work, but is also cumbersome.

Along the priority topic, I was always told that events in state machines were run sequentially in the order in the list, hence why the order can be changed. Since you bring up event priority and this seems to even span multiple states, is there a table available of event priorities?

mbowdich

Sorry for the delay. I currently don't have a list of the priorities of all the applications. I can tell you that "events" (such as calculation events) have a higher priority over "actions" from an application. So when you call events using "CCM -> FireEvent" from a state machine, they will take priority over action calls such as "CANOpen -> Tx Std Free Form (FFCAN Test Message)."

Brad Seidl

What about calling the CAN send event from a script. For example, I use a script to process and calculate the data I want, then I pass it back to the variable database [smWrite()], and fire a state machine event to send the data.

This process would be contained within a conditional statement in the script until all the data has been sent. Would this work? The script should be executed in line order, correct?

Unfortunately that would not work either. The priorities carry over to scripting too. If you had something like this in a script...

sendEvent(Calc1);
sendEvent(SendFF);
sendEvent(Calc2);
sendEvent(SendFF);
sendEvent(Calc3);
sendEvent(SendFF);

The calculation events would all calulate before the CAN message is sent out.

The same thing will occur using smWrite to directly write to a variable.

Brad Seidl

I'm thinking something like this (assuming handles and array have already been defined):
If not, what could be inserted to here to make it work? I really need to keep the amount of transmission latency a low as possible.

That will not work either.

To make it work you could use a state machine and script together. The state machine would be used to create the loop. The script would place your value in your variable.

I attached an example config

The state machine is looped with a timer so there is separation between writes and sends. A condition returns the state machine to the beginning when the variable "i" reaches 10. The script puts the current value of i in the Free Form CAN variable.

Brad Seidl

Unfortunately, this is an over-simplistic solution to a more complex task. I have some extensive handling to do with the data (an a lot of it, several thousand bytes) prior to sending it on the CAN.

Does the system actually have to exit the script and re-enter it, or can other processes internal to the script provide the separation. For example, I am manipulating the data, calling other functions and/or scripts, and accessing a file. Would any of those have effect on it?

I am really trying to avoid exiting the script, as some of the data is stored in an array, which I cannot make global because I do not know the size to declare until the script is already being executed.

Can you tell me where in the priority list that each of the following lie, and what else falls into the same range as the timer that can create the needed separation of events (both in state machines and in scripts)?

SendFF
Timer
Calculate
smWrite

*EDIT* 11:15 PM - I figured out how to get data into a global array, so I am now closer to making this work. Anyway, I still need to process the data from the array before sending it on the CAN bus, so the questions above still apply. I may be close to being able to implement this solution, but the timer adds latency, which may make it take to long.

Only state machines will provide the separation with timers. You can think of a script as a "state" in that events (CCM) will be executed before application actions.

The timer will add latency but you can experiment with the timer values to get the least amount of latency as possible.

Here are the priorities of your list...

smWrite -> this executes at the time you call it in the script
Calculate -> this executes after the script exits and is part of the CCM so has a high priority. All calculation events will execute before application actions in a state.
SendFF -> this executes after the script exits. It's an event that calls an application action so it has a lower priority than the calculation event. In a state machine, actions execute after events
Timer -> this just exits out of a state and provides separation between a state's events/actions

Brad Seidl

I've had some partial luck using sleep() in the script, and the results are consistant, but about 50% of the messages missed (calculations overwriting them). I'm currently tring to figure out what it is not all-or-nothing like the state machines.

I'm a little confused about this part:

Calculate -> this executes after the script exits and is part of the CCM so has a high priority. All calculation events will execute before application actions in a state.

You mention "in a state" but this is also true if you move to another state without some for of separation. That is why it fails even if I calculate, sendFF, move to a new state, calculate, sendFF. Is a timer the only thing that can make the separation?

Even with the timer value set at 1ms, my whole transmission on the CAN bus is taking over 6 seconds for something that should normally take about 200ms.

Yes, you are correct, a timer can only provide the separation between states in a state machine, so just using a transition will not work.

Brad Seidl