CODESYS - the IEC 61131-3 automation software

Welcome to the official CODESYS Forum
Deutsche Version English version russian version 
It is currently Fri May 25, 2018 9:27 pm

All times are UTC+01:00




Post new topic  Reply to topic  [ 5 posts ] 
Author Message
 Post subject: CAN CL2 Library Flaws
PostPosted: Thu Apr 17, 2014 9:28 am 
Offline

Joined: Wed Apr 16, 2014 3:10 pm
Posts: 2
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!


Top
   
PostPosted: Tue Apr 22, 2014 8:52 pm 
Offline
Site Admin

Joined: Mon Sep 05, 2005 9:42 am
Posts: 2671
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


You do not have the required permissions to view the files attached to this post.


Top
   
PostPosted: Wed Apr 23, 2014 1:15 pm 
Offline

Joined: Wed Apr 16, 2014 3:10 pm
Posts: 2
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


Top
   
PostPosted: Tue May 06, 2014 10:34 am 
Offline
Site Admin

Joined: Mon Sep 05, 2005 9:42 am
Posts: 2671
> 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


Top
   
PostPosted: Fri May 11, 2018 9:44 am 
Offline

Joined: Thu May 10, 2018 7:52 am
Posts: 1
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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 5 posts ] 

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited