[Mike Copioli]

Originally Posted by Radical Pi

The only thing that could potentially be removed from communications in the ACK from the jaguar, which would mean no error messages could be seen about a lost jaguar unless a requesting message was sent.

Removing the ACK would not be advisable and would further abstract the current implementation from the correct CAN implementation. All of the CAN transactions should be handled by the CAN nodes independently of the cRIO application. For example:

lets say we want to send set throttle to 8 Jags.

Current implementation

-set jag 1
-crio waits for ack
-set jag 2
-crio waits for ack
-set jag 3
-crio waits for ack
-set jag 4
-crio waits for ack

.......

All of this takes place over serial or Ethernet. Lets say each set command takes about 1 mS. Setting 8 Jags would take 8 mS.


Better approach:

Application sets all 8 throttles via gateway. Gateway sets Jag 1, Jag 2, Jag 3while application continues performing other tasks, ACKs are received by Gateway in or out of order. Time to set all 8 Jags less than 1 mS. The whole thing could be handled by one process CAN call. In this same approach requests could be made for current, position, and velocity. Application makes requests for Current, Position and Velocity from all 8 speed controllers. CAN gateway handles requests while application continues. No ack is needed for these types of requests because the response from the Jag is confirmation that the request was received. As you stated this is similar to how requests are made now. What really needs to change is the set throttle interface. The current configuration is more comparable to master slave rather than a true CAN bus where all nodes have the ability to communicate with each other.