> 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. 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). 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. 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. The LinuxCNC part of the CANopen driver could also be told to periodically produce PDO message that contains in bytes 4..7 the HAL pin image located in 3001:23. CANopen doesn't care how the data gets into 3001:23. The nodes out there don't care either. Any number of nodes can receive that PDO and grab the information in bytes 4..7. So you might have 3 different displays on a long manufacturing machine each showing the value reported in that PDO. 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. 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. 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. John _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
