Hello Pablo,
I looked at your model and I think I found a solution for your issue.
What I ultimately had to do was to set Can ID Message Type either to STANDARD or EXTENDED, for the RECEIVE objects. By keeping one of them as a polling hardware object, the MainFunction_Read is still necessary.
I chose STANDARD for CanHardwareObject_Can0_Rx_Std_Polling (id=1) and EXTENDED CanHardwareObject_Can0_Rx_Ext_Interrupt (id=2) (instead of MIXED).
Screenshot 2025-03-03 185902.png
With these changes alone I got the model to work in the following way:
- Sent EXTENDED frame from Can Analyzer - > started receiving EXTENDED frame messages with the ID incremented by 1 from the board
- Sent STANDARD frame from Can Analyzer - > started receiving EXTENDED frame messages with the ID incremented by 1 from the board
In case you are looking to also reply with the same message type, then you would need to implement a workflow that includes 2 Can_Write blocks (one with the checkbox for Extended enabled and one without), and based on the received frame, you redirect to the content to the appropriate Can_Write.
A few ideas on how you could differentiate between the frames:
- By received ID length, but this might be tricky depending on how this is stored
- By Hardware Object ID: going back to the configuration referenced above, CanHardwareObject with the ID 1 was set to receive STANDARD messages, so if your received CAN message comes from the object with the ID 1, you know it's a STANDARD message; otherwise if it's ID 2, then you know it was captured by the can hardware object with ID 2, configured to receive EXTENDED frames.
Please let me know if this fixes the issue you were encountering.
Regards,
Robert V