Den 2021-01-23 kl. 01:31, skrev John Dammeyer:
From: andy pugh [mailto:[email protected]]
On Fri, 22 Jan 2021 at 23:16, John Dammeyer <[email protected]> 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.
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.
Nicklas Karlsson
During the PRE-OP state the master can send Service Data Object messages (SDO)
which are a REQUEST/RESPONSE process. Once OPERATIONAL all nodes may transmit
asynchronously Process Data Object messages (PDO).
Devices may send Service Data Objects (SDO) in both pre-operational and
operational mode, message have priorities so it should even work well if
there is real time communication going on, there might be a need to do
configuration via SDO befor device enter operational mode. PDO messages
may be synchronized by a special SYNC messages but asynchronous is also
possible, most probably periodically sent SYNC message is the choice
then using it in Linuxcnc.
CANopen works with an Object Dictionary which theoretically is huge (greater
than 16MB) and a bit tough on an 8 bit processor with 64k addressability. So
the Object Dictionary is broken into a 16 bit index and 8 bit sub index pair
which points to a data object that could be a bit, nibl, byte, word and even
string. You can see how this quickly could become very large.
However internally the Object Dictionaries tend to be lists or groups of tables
that are accessed via binary searches so it's not as bad as it looks.
Device may follow a standard and best way is to use .dcf or .eds to put
name on the numbers.
To make LinuxCNC work with CANopen the ideal is to create an Object Dictionary
that has HAL pins mapped to Object Dictionary entries. Now the system master
can send an SDO request for the value of 3001:23 which has a size of 4 bytes.
The CANopen part of the driver then captures that HAL pin allocated to that
location and returns it in the Reply Data Object (RDO) message.
Not exactly I would say. Most important is the need to map data in PDO
messages into hal pins. There is standard entries dictionary possible to
access using SDO to tell how PDOs are mapped and is usually possible to
change these mappings if needed. Datatype vary in size and type, usual
numbers but also the little bit more unusual 24bit real.
Object dictionary devices is available in .dcf or .eds file.
...
The information for what's in a PDO and how often it's sent is also contained
in pre-defined locations in the Object Dictionary.
Exactly. Think you have to look into .eds or .dcf file to get the datatype.
It's not super complicated. But it requires something that can run apart
from, but has access to HAL pins and probably runs at the SERVO_PERIOD rate.
And obviously a method of updating/reading a 1 to 8 byte value without being
interrupted by some other task updating it at the same time.
A driver to send at least one message to put devices into operational
and a periodic SYNC message is needed. There must also be parameters to
map PDO data into hal pins and create the pins needed.
It is possible to do auto detection of devices by scanning bus but in
the end signals will be wired up the usual way in hal once figured out
there way should be connected regardless of how mapping is figured out.
The OD entries connected to HAL pins can be set to be Read Only so it's
possible to access motion values like position etc. without changing them. Or
they can be Read/Write so you can start or stop the spindle with an RPM value.
Yes there is a need for ordinary read/write access on pins as some
values flow one direction only. There is also a need for datatype size
and type on pins. And adding the pins needed. Pins not only with
connected devices but also depending on how they are configured, guess
explicitly adding these hal pins needed is the method.
Nicklas Karlsson
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
