Re: [Emc-users] CANopen on LinuxCNC

[Nicklas SB K. <nk...@nk...>]

CANopen protocol are used on both CAN and Ethercat networks. Should be 
possible to use same configuration method for both but driver to 
send/receive is different.

Familiar with CANopen if anybode need help there.


Den 2021-02-27 kl. 13:46, skrev Curtis Dutton:
> This sounds like the ethercat driver already does most of what you are
> discussing. It would be a good place to start if you planned on building
> something.
>
>
> On Sat, Jan 23, 2021, 2:24 PM John Dammeyer <jo...@au...> wrote:
>
>>> From: Nicklas SB Karlsson [mailto:nk...@nk...]
>>>
>>> Den 2021-01-23 kl. 01:31, skrev John Dammeyer:
>>>>> From: andy pugh [mailto:bod...@gm...]
>>>>> On Fri, 22 Jan 2021 at 23:16, John Dammeyer <jo...@au...>
>> wrote:
>>>>>> And I take it from your answer that this sort of driver at this
>> point in time does not exist.
>>>>> Not as far as I know, but it might be a fairly simple thing to create.
>>>>> It need to create HAL pins then gather the data from wherever, and put
>>>>> it on the HAL pins.
>>>>>
>>>>> --
>>>> That's probably more of a patchy method.
>>>>
>>>> CANopen has a number of states and needs some sort of master to
>> co-ordinate the state changes.
>>>> INIT, PRE-OPERATIONAL and OPERATIONAL are the 3 main ones.  There's
>> also an ERROR and STOPPING etc.
>>> If I remember correct CANopen devices start in pre-operational mode, a
>>> SYNC is usually sent periodically and just because of this.
>> The start with a RESET status message.  Then PRE-OP.  The SYNC is not
>> needed or required.  The transition to OPERATIONAL happens when the NMT
>> master decides it's ready for that.
>>
>>>
>>> Once devices are configured data in the PDOs need to be mapped in hal
>>> and this require some more driver support.
>>>
>>>
>>> It is probably also useful with SDO communication which is usually used
>>> to configure devices. Configuration may equally well may be done by
>>> external tool if CiA309-3 gateway is implemented, protocol is text but
>>> graphical user interface may communicate using it have, have a simple
>>> one currently hardcoded entries.
>> I disagree.
>>
>> The full CANopen spec is designed to be infinitely configurable making
>> much of it very complicated.  Dynamic configuration of devices on power up,
>> although possible isn't required for a fixed hardware product that doesn't
>> change.  This adds complexity.
>>
>> Once I finish my mill cabinet upgrade and a few other projects I do intend
>> on getting back to my CANopen Lite project which includes an application
>> for working with CANopen messages.
>>
>> Things were going really well until I ran into the issue that the Lazarus
>> sockets library did not support SocketCAN the way that the C and Python
>> libraries do.  Which means I have to upgrade sockets.pp first.  And that's
>> where I stopped and restarted other unfinished projects.
>>
>> The attached screen shots show however that it did work with the Lawicel
>> CANUSB.  This software is written with the "Write Once" "Compile anywhere"
>> model and therefore has been tested and runs on WIN-7, WIN-10, Raspberry
>> Pi3B, BeagleBone Black and LinuxCNC.
>>
>> CANopen Lite is designed to work as a simpler version of CANopen that
>> doesn't have all the bells and whistles that a full CANopen implementation
>> might.  However it has been tested with COTS CANopen devices like displays,
>> battery chargers, and CANopen based servo motors.
>>
>> In addition to the desktop application there will be a number of different
>> CANopen device samples that demonstrate how to create say a display module,
>> relay module or I/O module etc.  Maybe even a motor or two.
>>
>> Mapping HAL PINs into Object Dictionary locations is the easiest way to
>> deal LinuxCNC.  A readable configuration file in the same way that the HAL
>> file is read on start-up is one way to populate the object dictionary with
>> the HAL PINs that someone will want made visible on the CAN bus.  It will
>> all depend on how access to the PINs is granted at the core program level.
>>
>> Anyway, it's a work in progress.  Be a few months before I can get back to
>> it and I really want access to Raspberry Pi HAT MCP2515 CAN devices and the
>> internal CAN devices in a Beaglebone Black.  And for that, there's some low
>> level OS library work required.
>>
>> John Dammeyer
>>
>>
>>
>> _______________________________________________
>> Emc-users mailing list
>> Emc...@li...
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users