Help

CAN CL2 Library Flaws

I'm currently working on a project which includes a non-CANOpen CAN protocol. I've implemented a CAN library from the bottom up, using the CL2 library.
All the CAN functionalities are working fine, yet there is this one annoying thing about the CL2 library: every message that has been transmitted by the controller, is stored in the same queue as the messages that are received by the controller. The result of this is: when I want to read my incoming CAN messages, I've got to check every single time if the message is a transmit message or not (using CL2.IsTransmitMessage) and immediately free the message when it is a transmit message. When I'm sending messages at a short interval, my queue threatens to overload, blocking my incoming messages and the cycle time of my program increases because of all the messages that have to be freed. I'm aware that the Tx messages are stored in the queue in case one would like to check the send time of the messages, but when this option is not required it is just a very annoying obstacle.
Is there any possible way to keep the transmit messages out of my receiver/receive queue?

Another thing that drew my attention is the fact that the CL2.DriverOpenH function generates a "WRONG_BAUDRATE" error when a baudrate other than 250 kBit/s is selected. The CAN interface however works just fine on any selected baudrate, so the error is invalid. Is this just hardware (controller) dependent or is this a common problem?

My last question: I'd like to use the CL2.DriverOpenP FB to create a driver handle so I can determine the memory for the interface myself instead of allowing the system to use memory from the heap, but when I use this function instead of CL2.DriverOpenH, no handle is created. Not even a error is created (and yes, I am providing the proper inputs to the block) so I have no clue why this wouldn't work.

I'd be very grateful if someone from CoDeSys could respond to these issues, thanks in advance!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

which plc are you using, we need a little bit more information,
for us it sound like CL2 problems. (who has implemented the 'can mini' driver?)
You could configure if your messages should occure in the rx Queue.

BR
Edwin

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

I'm using a PLC board from Inomatic, a fairly new system. The problem with the transmit messages in the queue has been fixed, you were right about the masking, this has fixed the problem.
The other two issues still stand though, I'm still unable to use the CL2.DriverOpenP function, it's not creating a handle nor a error. Could it be that the hardware doesn't support this function? The CL2.DriverOpenH function is working fine.
The thing with the inappropriate baudrate error isn't really a problem to me, it's just something that drew my attention and it might be an interesting bug to fix.

Kind regards,

Jarno

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

CL2.DriverOpenP function, it's not creating a handle nor a error
The WRONG_BAUDRATE error is not normal. There can be several reasons:
a. CAN driver for this platform returns an error on DriverOpen
b. An invalid Baudrate is used.
c. The driver was already opened with another Baudrate.

CL2.DriverOpenP is currently not implemented.. think you Need to ask Inomatic for more details & Support

BR
Edwin

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Edwin Schwellinger hat geschrieben:
Hi Jarno,
which plc are you using, we need a little bit more information,
for us it sound like CL2 problems. (who has implemented the 'can mini' driver?)
You could configure if your messages should occure in the rx Queue.
BR
Edwin

Hi there,

How does adding a xTransmitMask, xTransmitValue solve the problem? What is the logic behind it?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

CODESYS Group | We software Automation.
The CODESYS Group is the manufacturer of CODESYS, the leading hardware-independent IEC 61131-3 automation software for developing and engineering controller applications.
3S-Smart Software Solutions GmbH
A member of the CODESYS Group
Memminger Straße 151, 87439 Kempten
Germany
Tel.: +49-831-54031-0
info@codesys.com