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:
Hi all,
I am using the CL2 library too with TM258LF42DT PLC. But, I don't know how to fill the CAN data part. It seems that there is no place to fill the CAN data in CL2.CreateMessage().
Input:
hDriver CAA.HANDLE Handle of CAN interface
cobId CL2I.COBID Message ID
usiLength USINT number of data bytes in message
xRTR BOOL RTR flag of message
x29BitID BOOL FALSE: 11 Bit-Ids only; TRUE: 29 Bit-Ids also supported
peError POINTER TO CL2.ERROR pointer to error code (enumeration type)
Output:
hMessage CAA.HANDLE handle of message
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:
Dear all,
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!
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
Thank you for your reply Edwin!
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
CL2.DriverOpenP is currently not implemented.. think you Need to ask Inomatic for more details & Support
BR
Edwin
Hi all,
I am using the CL2 library too with TM258LF42DT PLC. But, I don't know how to fill the CAN data part. It seems that there is no place to fill the CAN data in CL2.CreateMessage().
Input:
hDriver CAA.HANDLE Handle of CAN interface
cobId CL2I.COBID Message ID
usiLength USINT number of data bytes in message
xRTR BOOL RTR flag of message
x29BitID BOOL FALSE: 11 Bit-Ids only; TRUE: 29 Bit-Ids also supported
peError POINTER TO CL2.ERROR pointer to error code (enumeration type)
Output:
hMessage CAA.HANDLE handle of message
Hi there,
How does adding a xTransmitMask, xTransmitValue solve the problem? What is the logic behind it?