Exotic data types in .xml config
01 Aug 2024 09:13 - 01 Aug 2024 09:32 #306594
by endian
Please Log in or Create an account to join the conversation.
02 Aug 2024 14:18 #306741
by scottlaird
Replied by scottlaird on topic Exotic data types in .xml config
Ah, yeah, the EL6751. I keep meaning to get around to trying to use mine for something, but it looks like more work than I really want right now 
.
The problem with mapping anything more complex than ints or floats is that LinuxCNC doesn't really have a good type to hold them, so there's no good way to create a pin for them. Even if we had an array of ints, there's no array type in LinuxCNC. OTOH, a fixed-size array is pretty trivial to map to 8 individual ints.
I'd love to see a working EL6751 config for *anything*; IIRC people have claimed that they've got it working once or twice, but I don't think we do a very good job at it.
If we *really* wanted to do a good job with the EL6751, we'd probably want to refactor LCEC to create a generic CANopen layer (PDOs, SDOs, etc), and then tie that to a lower-level EtherCAT layer plus a lower-level CANopen layer. Then the EL6751 could be a CoE EtherCAT device that exports a CANopen interface that we could run CANopen devices on top of.
That'd let us use generic CAN devices, and maybe even some RS485 devices, in addition to the EL6751 for talking to CANopen CiA 402 devices and so forth.
Except we don't actually *want* to use most CAN CiA 402 devices, because they don't support CSP/CSV modes, because CAN isn't fast enough. Mostly.
Anyway, it'd be a lot of work, and I'm not sure that there's a real payoff.
.The problem with mapping anything more complex than ints or floats is that LinuxCNC doesn't really have a good type to hold them, so there's no good way to create a pin for them. Even if we had an array of ints, there's no array type in LinuxCNC. OTOH, a fixed-size array is pretty trivial to map to 8 individual ints.
I'd love to see a working EL6751 config for *anything*; IIRC people have claimed that they've got it working once or twice, but I don't think we do a very good job at it.
If we *really* wanted to do a good job with the EL6751, we'd probably want to refactor LCEC to create a generic CANopen layer (PDOs, SDOs, etc), and then tie that to a lower-level EtherCAT layer plus a lower-level CANopen layer. Then the EL6751 could be a CoE EtherCAT device that exports a CANopen interface that we could run CANopen devices on top of.
That'd let us use generic CAN devices, and maybe even some RS485 devices, in addition to the EL6751 for talking to CANopen CiA 402 devices and so forth.
Except we don't actually *want* to use most CAN CiA 402 devices, because they don't support CSP/CSV modes, because CAN isn't fast enough. Mostly.
Anyway, it'd be a lot of work, and I'm not sure that there's a real payoff.
Please Log in or Create an account to join the conversation.
02 Aug 2024 19:24 #306784
by endian
I will manage it and let you know how it should be... but I think it will be pain to do it...
Can you tell me how difficult is to create device.c and .k to define device via non generic definition please?
exactly I thinking about it the same... new layer for canopen slaves and add them to ethercat xml as generic... I will try to map them as complex a split them out via bits to something what lcnc will understand... RS485 is great but Profibus interface should be greater for us... there is whole galaxy of non supported devices as vfds and pneumatic terminal which should be usable ...I saw some project on this forum with profibus but it was in the python ..
regards
Replied by endian on topic Exotic data types in .xml config
yes for sure, CANopen is not a RT bus.. it is light weight and most cost effective pocket swiss knife ... I think when you will not use a CSS and rigid tapping a CANopen vfds should be usable as really budget cost solution...Ah, yeah, the EL6751. I keep meaning to get around to trying to use mine for something, but it looks like more work than I really want right now
The problem with mapping anything more complex than ints or floats is that LinuxCNC doesn't really have a good type to hold them, so there's no good way to create a pin for them. Even if we had an array of ints, there's no array type in LinuxCNC. OTOH, a fixed-size array is pretty trivial to map to 8 individual ints.
I'd love to see a working EL6751 config for *anything*; IIRC people have claimed that they've got it working once or twice, but I don't think we do a very good job at it.
If we *really* wanted to do a good job with the EL6751, we'd probably want to refactor LCEC to create a generic CANopen layer (PDOs, SDOs, etc), and then tie that to a lower-level EtherCAT layer plus a lower-level CANopen layer. Then the EL6751 could be a CoE EtherCAT device that exports a CANopen interface that we could run CANopen devices on top of.
That'd let us use generic CAN devices, and maybe even some RS485 devices, in addition to the EL6751 for talking to CANopen CiA 402 devices and so forth.
Except we don't actually *want* to use most CAN CiA 402 devices, because they don't support CSP/CSV modes, because CAN isn't fast enough. Mostly.
Anyway, it'd be a lot of work, and I'm not sure that there's a real payoff.
I will manage it and let you know how it should be... but I think it will be pain to do it...
Can you tell me how difficult is to create device.c and .k to define device via non generic definition please?
exactly I thinking about it the same... new layer for canopen slaves and add them to ethercat xml as generic... I will try to map them as complex a split them out via bits to something what lcnc will understand... RS485 is great but Profibus interface should be greater for us... there is whole galaxy of non supported devices as vfds and pneumatic terminal which should be usable ...I saw some project on this forum with profibus but it was in the python ..
regards
Please Log in or Create an account to join the conversation.
Time to create page: 0.085 seconds