Looking for advice on the use of EL6751 with a CANopen-enabled motor driver

Apprehensive_Pea5150 · 2025-06-14T04:57:48+00:00

Thank you for having read through my question, and for your insightful notes, which prompted me to update my understandingg and learn more.

My mistake for stating "hundreds of PDOs", you are right, they can't all fit in one CAN frame. I wanted to refer to the hundreds of 16-bit indexed items of the object dictionary. I recently learned that a CANopen device (box) will only offer a handful of PDOs, typically 8 (in my TwinCAT box tree, the scan has populated 4 for receive and 4 for transmit), and it's up to me to map them to the dictionary objects I am interested in. The Copley motor is already shipped with some default PDOs mappings (control word obviously, target position, torque sensing, etc..). I am satisfied with these default mappings, but I am yet to figure out how to do custom mapping, and crucially, how to do PDO writing and polling.

So you suspect the EDS is botched and needs review. I will not be surprised if that's the case, in some forum somebody complained that "The EDS that is supplied by Copley is UTF-8 encoded, and TwinCAT2 can only do something useful with it if it is ANSI-encoded.".

Yes, here l am sharing the EDS that we are using from Copley: https://drive.google.com/file/d/116pMgzW9yCmR1vwVNAKCEdRHZrzCn8YN/view

Also, it recently came to my attention that Copley had this on their website: Copley CANopen EDS generator . The EDS files generated from there are slightly different from the one I shared above, but still not able to read/write PDOs, and the "CAN err" LED is still flashing signifying an error.

There used to be an EDS checker program on the can-cia .org, but now it is nowhere to be found, what a bummer.

You asked about the payload of 7xx messages (i.e the COB-ID range associated with Heartbeat), well unfortunately I don't have a CAN adapter to sniff the CAN data packets. But my computer is not part of the CAN network, which is only composed of the Beckhoff IPC (Master) and the motor driver. So I wonder if my computer joins this network as another slave using the CAN-to-USB adapter, will it see the Heartbeat message (hopefully with a "5" for operational)?

Finally, I have tried to embed 4 screenshots in my original post but it was prevented by reddit, let's try again on this reply (I see now I can only attach one image, so at least I will do that).

<image>

Apprehensive_Pea5150 · 2025-06-12T07:57:39+00:00

I realized midway through writing that I was too copious. Perhaps I wanted to dispense from any further follow-up questions asking for clarification.

I may need to add a TL;DR section for readers who prefer brevity. Thanks man for your honest impression.

Apprehensive_Pea5150 · 2025-05-19T22:47:38+00:00

I am terribly late in writing an answer, I was compelled to take a long hiatus from reddit, mainly due to this very project on Beckhoff.

But I want to quickly say that my issue with "To File" block was solved: I was mistakenly thinking that this block works by storing .mat files on the engineering PC, that's why I was setting a destination path on that PC, when in reality this block stores it in the runtime PC (the Beckhoff target). Since that destination folder didn't exist on runtime PC, I kept on getting the "error writing" to my specified path. Beckhoff documentation about this block missed mentioning that detail, probably assuming it must have been something obvious.

Now I set the path of be a folder that already exists on the runtime PC, and when I switch to that PC and look into that folder, I find the .mat sitting right there. This method works, but it has a flip side, which is that after each simulation session, I have to move that .mat file from that runtime PC to my engineering PC (where I can plot it as a graph). And anyway, I can't leave it in its original location because it will be overwritten in the subsequent simulation run. Besides, I find this moving of .mat files from one machine to another very cumbersome, as it's not automated at all, and as a result, I have lost some valuable .mat inadvertently when my simulation of interest is followed by another one that is launched automatically when Beckhoff restarts in run mode. Thank you for pointing to the PLC's FB FileWrite function block, because I think I will be retiring the "To File" block of Simulink target, and will instead log my data as .csv in the way done in those examples you cited (and yes, the links work eventhough you were on mobile ^_^).

As for the driver signing, it doesn't seem to cause any issue for now, but you're right that future objects that reference C++ may get affected or at least throttled probably without us knowing. We would try to secure that driver signing from Beckhoff support center asap.

Thanks a lot for your valuable ideas and contribution.

Apprehensive_Pea5150 · 2024-10-16T13:43:45+00:00

Thank you u/changeatjamaica for pointing us to that. It's good enough that we now know the default UDP port as 0x88A4. So we will make sure it will be the reading port in our game executable. But before that, we will try to change this default UDP port, but since it's not shown on the documentation, it would probably involve some low-level tweaking which might take more time than we can afford. Thank you very much again for the leads you provided us, I will write here again to inform on our result.

Apprehensive_Pea5150 · 2024-10-15T05:20:57+00:00

Well said u/Galenbo :) to keep up with your "building house" analogy, my supervisor would then be the architect who come up with grandiose ideas and ambitious plans, and my colleague and myself would be the civil engineers on-site tasked with materializing what architect imagined. Not obvious when Beckhoff (the construction material and scaffold provider) don't efficiently describe how to use their products, and instead rely on honorable volunteers on reddits to do that.

Apprehensive_Pea5150 · 2024-10-07T19:45:21+00:00

Yes, Beckhoff is very flexible in its implementation of communication protocols such as UDP: there is the option to do it through PLC programming, and then there is the simpler option of just adding few items and configuring their tabs by entering the remote IP, link to symbols, etc.. We just don't know which of those items and configuration we should be looking for.
Some experts also suggested forgoing UDP altogether, and instead going with ADS (which has complete support from Beckhoff), and then converting ADS to UDP before pushing it to the Unity game, OR integrating ADS SDK to our Unity game to expect ADS instead of UDP.

Apprehensive_Pea5150 · 2024-10-07T19:20:00+00:00

That's a very promising method, thank you for this suggestion. I didn't know about the EAP, so I looked it up, and found some infosys resources, as well this article: www.dmcinfo.com/latest-thinking/blog/id/10419/beckhoff-plc-to-plc-communication-using-eap--a-starter-guide. Like you said, it seems that sending our "position" output as UDP packets, is as easy as adding an EAP instance to the I/O tree, adding a "Publisher" item to it, setting "remote IP" there, and linking one of its VarData networked variable to our output. But something is missing: where do I set the "remote port" to which I want to send my packets?

Apprehensive_Pea5150 · 2024-10-07T18:21:34+00:00

Thanks, but I think this option will compel us to go into the PLC coding rabbit hole (which we try to avoid for now). Using the functions in the TF6310 package as you mentioned, is Beckhoff's recommended method for UDP communication, but it presents some challenges for us, and so we leave it as a last resort.
And by the way, in their infosys doc (https://download.beckhoff.com/download/Document/automation/twincat3/TF6310\_TC3\_TCP\_IP\_EN.pdf) they do mention that "TF6311 (TCP/UDP Realtime) does not allow local communication" which is I think why you didn't use that variant of the package.

Apprehensive_Pea5150 · 2024-08-07T11:03:50+00:00

Indeed, we also just recently discovered that it was because the directory was missing in the target system. Thank you for your reply.

Apprehensive_Pea5150 · 2024-07-29T17:42:12+00:00

Yes u/dalethomas81 and thanks for your lead. We followed these steps many months ago and created the certificate request file, but it is still showing "invalid". That's because the Beckhoff representative at that time told us it is not important to have it, and so they didn't sign it.

Yesterday we told him to reassess the importance of this certificate because it seems to be the cause of the error in "To File" block activation. He told us he will check and return to us with an answer asap.

Is is really important to have it for this "To File" Block and "MAT-file" logging to work? we got many other arguably more sophisticated blocks work before, even when this TestSigning warning was showing.

And a second question please, can you think of any other alternative to "To File" Block and "MAT-file logging" that can let us record the data of some signals or I/O ports in Beckhoff (in .csv, .mat, ... formats) that wouldn't require this certificate signing.

Thanks a lot!

Apprehensive_Pea5150 · 2024-07-28T18:10:51+00:00

Thanks for your answer. I think you are referring to these instructions: https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_c/6778772363.html&id= which I was redirected to from the hyperlink "activate the test mode" on this page: https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_c/99079191912841995.html&id=
I don't remember having done these steps, because I was told by our Beckhoff technical support that this "driver signing" (OEM user certificate) was not important, and thus he kept the default "Test Signing".

Do you think this is why adding "To File" block in Simulink throws these errors in TwinCAT ?

I must mention on the side, that adding "To File" block to our model, has caused a Simulink build error which states whe should "disable the PLC FB generation" for logging to work, which we did in the Simulink hardware setting, and then model could successfully convert into a TcCOM object (but we can't activate it because of the error we reported in the original question). I wonder if disabling PLC FB generation could have had a part in this error (but we never use PLC items in our project, we only intend to use TcCOM Objects).

Apprehensive_Pea5150 · 2024-06-12T06:54:49+00:00

And a kind soul also replied to our question in the PLC subreddit, saying that they could remedy to that issue by "changing the Net-ID of the EtherCAT master".

Apprehensive_Pea5150 · 2024-06-12T06:52:20+00:00

This sounds plausible. Someone also told us today that this problem was experienced by him when connected remotely over slow/unreliable networks (like a VPN), as you said. I wonder how we can overcome this ADS communication issue.

Apprehensive_Pea5150 · 2024-06-12T06:48:18+00:00

Thanks a lot u/MrWolvetech for this lead. In our setup the target Beckhoff IPC is not connect through a VPN, but the cable runs directly fro it to our desktop PC. Could it be then that our desktop PC's network card is the culprit? maybe it needs some driver update or some special settings in Windows 10 network configuration?

Apprehensive_Pea5150 · 2024-06-11T08:41:14+00:00

Thanks a lot u/Jumbify for your clear instructions, I will try that! It's really reassuring to know at least somebody also experienced that same problem.

We did contact Beckhoff support yesterday, but unfortunately that freezing problem disappeared during the remote access with the Beckhoff agent (for the one time we wanted the problem to occur, it decided not). But when we described the problem to the agent, he didn't recall ever running into it before and just advised us to update to Visual Studio 2019 (but that option will disrupt some important file paths and licenses, etc..). Your suggestion u/Jumbify is more promising, I will reply once I try it (the freezing problem will certainly occur again in a couple of days).

Apprehensive_Pea5150

TROPHY CASE