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...@autoartisans.com> wrote:
From: Nicklas SB Karlsson [mailto:nk@nksb.online]
Den 2021-01-23 kl. 01:31, skrev John Dammeyer:
From: andy pugh [mailto:bodge...@gmail.com]
On Fri, 22 Jan 2021 at 23:16, John Dammeyer <jo...@autoartisans.com>
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
