-
|
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.
-
|
Based on the logs you attached for these two 4640 cases, the DDOP was uploaded OK, and appears to be valid... no corruption that I can see, and the error the TC returned
So I guess, to me it all looks OK - I'm not sure why the Deere TC would reject this DDOP! I will see if I can learn more about what the Deere display might be mad about, but in this case at least, it seems the stack was working as expected. In the meantime, I'll take a look at that 2630 log. |
Beta Was this translation helpful? Give feedback.
-
|
Did you extract that DDOP from the CANtrace? How can I do that? |
Beta Was this translation helpful? Give feedback.
-
|
I did! The binary DDOP is in this zip file if you'd like it. To be honest I used regex matching in VS Code to delete all non-tp messages, then did some copy-pasting to make a C array to re-export as a binary file with a little C program haha, very manual process. I should probably script it 😅 |
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.
-
|
This log was very fun to look at, so many weird things happening! The short version:
The long version: There are two Deere devices claiming the Task Controller function, which is itself not strange, but then only one of them sends the status message, and the other one really likes to send nasty 11-bit ID messages and proprietary B broadcasts, so it doesn't seem to actually be a TC... very strange. This CF relocation looks incorrect, as the one at address 210 (0xD2) has a different ECU and function instance. So, that is probably a bug in the stack. I will open an issue to investigate it. But, I think you could work around this by adding some additional NAME filters to the TC example (or seeder example). Basically, you'd just need to filter for the TC with ECU and Function instance of 0. Something like this: |
Beta Was this translation helpful? Give feedback.
-
|
You are a genius!! I still need to do some research, e.g. why it's not coverage mapping (I suspect it to be due to the lack of a proper speed signal from my simulated Tractor ECU) but I think, I can get that sorted... |
Beta Was this translation helpful? Give feedback.
-
|
seeder example: |
Beta Was this translation helpful? Give feedback.
-
|
Other Examples that use an object pool, such as virtual_terminal/version3_object_pool fail as well with the CC4600: I'm going to try with another CC4600 equipped tractor as well later |
Beta Was this translation helpful? Give feedback.
-
|
Ok, here it is. I did two things: Even though I think there's little to no new information in it, I'd like to share the results: tcclient, CC4600, JD6155R, incab: tcclient, CC4600, JD6155R, incab, early failure: tcclient, CC4600, JD6155R, breakaway plug: |
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.
-
|
Ok, I'm back in the cab. Here's what the tc client application gives me when connected to my CC4600: |
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.
-
Thinking about it, I'd like to try one more thing -- I've connected the CC4600 (which showed the sequence number issue) using my laptop and the Lawicel CANUSB adapter, whereas the 2630 and the 4640 (which didn't show the sequence number issue) were connected to my PC using the USBTin adapters. Even though I've been using the Lawicel adapter a lot in the past without any problems, I think I need to really verify it's working correctly without dropping frames... |
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.
-
|
Does AgIsoStack++ happen to implicitly create such child references for sections? |
Beta Was this translation helpful? Give feedback.
-
|
Sort of? When you create any device element, you specify the parent object ID, which then becomes part of the object's data. In our case, this is object 9, the "boom". You also can provide a list of all child objects of a device element by object ID. In the original example, we were doing both. So in other words, the original example has a bidirectional link between sections and the boom. I guess that's why the Deere display didn't like it? |
Beta Was this translation helpful? Give feedback.
-
|
Sounds reasonable to me. For a definitive answer on why the Gen4s don't like the bidirectional reference, we'd have to ask someone who knows their TC's implementation details, I suppose. |
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? |
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?