-
First of all I'd like to say thank you for such a great project. I really appreciate AgIsoStack++ being around. I wanted to give your examples (especially task_controller_client) a try and fired it up, but the attempt to upload the DDOP seems to be rejected by the TC Server (JD Command Center 4600):
With my GS3 2630 Display even less is happening:
All other examples (such as e.g. version3_object_pool) don't work either:
Same applies for the advanced seeder example:
There seems to be a general problem. I suspect the CAN connection to not work properly, even though messages go back and forth the bus (as candump shows). As I'm unsure what further information might be necessary to track down this issue, I'm going to list everything I deem relevant:
Thanks a million! |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 28 replies
-
Hello! We'd be happy to help you with some troubleshooting! Thanks for the detailed descriptions of whats happening. At first glance, I agree that it seems like there might be something not quite right with the bus or your connection to it, but what would really help us know for sure is if you could provide a candump or two. For example, in the first case with the task controller, the stack seems to think that the TC sent an ETP abort during the transfer of the DDOP, which is very strange and could indicate messages getting lost or corrupted or something. That said, the issue with the 2630 may be a different issue, as I can see that there's something at a TC's preferred address So, when you have time: |
Beta Was this translation helpful? Give feedback.
-
Hello Adrian,
By the way I changed the manufacturer code to 362 ("Alois Poettinger...") because I deemed 64 "Unused" a little bit suspicious. (With no effect, it behaves exactly the same) More CAN traces and reports to come (2630 etc.)... |
Beta Was this translation helpful? Give feedback.
-
Something very similar happens with the seeder example:
Started the seeder application again without restarting the display:
|
Beta Was this translation helpful? Give feedback.
-
On my 2630:
Nothing new appears on the display. No messages, no errors, except for the Controller to be enumerated in the controllers list (with correct industry group, device class, manufacturer code etc.) Oh, and by the way, it occurred to me, that I've changed the address from 0x1C to 0x1E (no effect noticed). |
Beta Was this translation helpful? Give feedback.
-
Tomorrow I'll try to run the seeder example on my Command Center 4600. |
Beta Was this translation helpful? Give feedback.
-
It seems to me like these CC4600 ETP aborts are some issue on the Deere side or with the bus, which is a little frustrating. Basically their device is telling us, "you can send me 255 frames at a time", but then after 80-100ish frames, they are telling us "okay, wait no, stop that" haha. Really though, they're telling us they received a bad sequence number in the ETP session, which is not reflected in the candump - all the sequence numbers were there and in the right order. Some things that could cause this would include: some bridge device on the bus failing to properly forward the frames, the bus being in a bad state, maybe not properly terminated, maybe a star architecture, maybe a software bug in the Deere display, maybe some issue with socket CAN actually sending a frame (??) there's many possible causes. So, I think we've got a few options knowing that... we can:
I can open issues to improve these things, though they're kind of just "band-aids" for whatever is going on with that bus I think. On a different note, after a little investigating the 4640 issues with the DDOP might just be that it doesn't like some of the content of the boom object, so we might want to try a stripped down version of the DDOP with it. I'll try and make a branch with a smaller version of that DDOP to try out. The only other thing that I thought of (though maybe a long shot) is that perhaps the Deere system needs some software unlock to allow random non-Deere ISOBUS devices to upload a boom to their TC? That at least feels like something they might do... just something to consider. |
Beta Was this translation helpful? Give feedback.
-
Well, other, non-Deere (I'm using WTK, a couple of Mueller Elektronik, and Kverneland Controllers) ISOBus-devices work well with all of my Deere Terminals. But there's one thing I should probably mention: I'm also not sure if this might help, but I've connected a TC of my planter (Mueller Elektronik) and recorded a can trace: Again, thank you very much for all your efforts! I really appreciate that! |
Beta Was this translation helpful? Give feedback.
Looking into it, apparently ISO11783-10's Section A.3 defines that the list of referable child objects for a device element object consists only of DPDs and DPTs, so I guess that answers that, haha. I will correct the example code and add to our validation that all children of DET objects are only DPDs ore DPTs. Sound good to you?