Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched. Close

CAN CL2 Library Flaws

jarno
2014-04-17
2019-07-10
  • jarno - 2014-04-17

    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!

     
  • eschwellinger

    eschwellinger - 2014-04-22

    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

    IMG: CL2.jpg

     
  • jarno - 2014-04-23

    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

     
  • eschwellinger

    eschwellinger - 2014-05-06

    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

     
  • xuepeng531 - 2018-05-11

    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

     
  • Kalyani-K - 2019-07-10

    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?

     

Log in to post a comment.