Quote:
Originally Posted by mjcoss
One thing that I have seen which is causing no end of issues is that if you get a timeout on the messages, the API is return no indication of the failure. So, for example, if the GetForwardLimitOK() function is called, and times out, you get back false. There is no way to know that that has happened and if you are making decisions based on these results... We have an encoder on our lift mechanism. To zero the encoder, we drive to the bottom limit switch, and when we get there, we set the encoder to 0. This works fine until we lose the message due to timeout. From that point on the lift is offset by where ever the timeout occurred. There really needs to be a way within the API to detect that the transaction timed out.
|
Yes... that's a definite shortcoming of the C++ API. Both the LabVIEW and Java CANJaguar APIs have a mechanism for the user's program to know that there has been an error. I intended to remedy that this season, but didn't have the time. It will be fixed next year.
Quote:
Originally Posted by mjcoss
All in all, I'm really regretting the decision to use the CAN bus. And for the most part all of the features that I really wanted to use, that were provided by the CAN bus, proved to be unusable.
|
I'm sorry to hear that you aren't happy with the CAN implementation. What features did you want to use that you aren't using? What made them unusable for you?