ad3154
commented
11 months ago Thought number 1
I'd need a candump to be totally sure, but this is most almost always an issue with CAN adapters and their underlying OS drivers or configuration that cannot support the full 250k baudrate of ISO 11783 or struggle once their internal buffer is full in some way, such as transmitting messages in an unpredictable order.
Basically what is happening is that we, by default, try to shove 256 ETP frames into the CAN driver as fast as possible over and over during an object pool transfer (with some waiting while the recipient clears us to send the next 256). Some CAN adapters handle this really well, and others choke for one reason or another.
SLCAN for example will not work well on an ISOBUS at 115200 baud or even 256k on the serial link - you'd want several M-baud I'd bet to ensure smooth operation due to the overhead of using it, which is out of the control of our library, so maybe mess around with that a bit, but ideally I'd suggest trying with something a bit higher-end, like a PEAK adapter or something.
That being said, one thing you could do in the examples to ensure this ETP session completes would be to seriously throttle the ETP session on the client's end by adding these lines somewhere before initializing the VT or TC clients:
isobus::CANNetworkManager::CANNetwork.get_configuration().set_max_number_of_etp_frames_per_edpo(16);
isobus::CANNetworkManager::CANNetwork.get_configuration().set_max_number_of_network_manager_protocol_frames_per_update(4);You can even drop those lower if needed, especially set_max_number_of_network_manager_protocol_frames_per_update can go all the way down to 1.
The first one tells the stack that instead of 256 frames, you want to only send 16 at a time. The second one tells the stack that you want to insert some delay between every 4 frames, which gives the adapter and the TX loop in the hardware layer some time to process what we already gave it.
This will seriously slow down the object pool transfers and may avoid your issue, but it's not ideal since other devices on the bus will not slow down for you.
Thought number 2
The Trimble display may be choking on its end! A candump from a different adapter on the bus during this transfer would allow us to tell if this is the case. If this is indeed the case, then throttling the connection as I mentioned above is about all you can do.
Hope this helps, let me know if you get past the issue or if you remain stuck.
GwnDaan
I have a problem running Task Controller Client example with Trimble GFX-750.
I also tried all examples with VT Terminal with similar errors but different PGN number. Do anyone have any idea what's wrong with my setup?