search

machinekit / machinekit-hal

Universal framework for machine control based on Hardware Abstraction Layer principle
https://www.machinekit.io
Other
106 stars 62 forks source link

library for devices in bus systems #127

Open ArcEye opened 6 years ago

ArcEye commented 6 years ago

Issue by luminize Fri Apr 24 17:48:18 2015 Originally opened as https://github.com/machinekit/machinekit/issues/583

With the prospect of CAN hope on Ethernet, and possibly many other bus systems we might think a bit in advance for not doing stuff twice.

One of the things that comes to mind is that it's not entirely strange to expect MK having 2 or more busses, with different devices in those busses.

Do we need to think ahead with respect to knowing all the unique devices, and is it important to know on what bus they are. In other words, Do we need something like a "device library" where MK knows (and can traverse for whatever obscure reason) the devices, regardless which bus they are on.

From technical point of view I can fathom a HAL CAN driver, but also a HAL Ethercat driver, or a HAL profibus driver etc etc. Such a component would upon initiation determine pins depending on the devices on the bus (some probing routine). so the result could be pins like:

another way (and I don't know the pros or cons) could be to have the driver components initiate other components like

2 important questions (i hope i properly distilled them)

ArcEye commented 6 years ago

Comment by jpmoniz Fri Apr 24 18:00:04 2015

Bas

I work on large distributed automation systems running multiple networks. For example one machine can have devices on Devicenet(CAN) ,EthernetI/P and some Motion over Sercos.

From the PLC's view there all just tag-names to me, and I could really care less, if the Bus Identifier was included in the name.

Fundamentally CANopen (and as far as I know Ethercat) rely on a configuration in the Master to tell it what devices exist on the network and their data formats. That configuration is what should probably drive pin/device names. I would Think.

ArcEye commented 6 years ago

Comment by luminize Fri Apr 24 18:18:17 2015

true, pin names must be derived from the info of the bus. That means polling the bus (CAN thinking here) and when a response comes from a device than it's there. After that we know what devices are on the bus.

I'm more thinking about the MK stuff, like wiring up component pins, doing it via a script for example, I can imagine that when you know how many "device1" there are in your machine it makes life easier to think about "device1" instead of making the distinction between which bus they are on.

I see the bus itself also as a "device" (plumbing)

ArcEye commented 6 years ago

Comment by jpmoniz Fri Apr 24 18:38:07 2015

Yeah,

Forgive me, I haven't yet exactly configured an EtherCat or CANopen system yet. I will be trying the Ethercat stuff tonight with MK.

From my experience with Devicenet(CAN based network) The Master was also termed a "Scanner". One would have to launch configuration software to add devices to the network and conversely map the device slave I/O into the Master module aka Scanner. This means that new devices added to the network would never be seen unless the scanners configuration was updated.

I would think in this case the same still applies. The Master would have a configuration (XML,INI what have you), that would define the devices on the bus and allow for logical naming of said device.

I would expect at time of loading the config would be parsed and depending on the configuration HAL device components would be created with logical names.

Am I making sense?

Yes the bus should also be treated as a device with HAL pins that have status and possible configs options I would think.

ArcEye commented 6 years ago

Comment by mhaberler Sat Apr 25 05:59:17 2015

I see your point in hierarchical naming according to bus topology (type/number/deviceid etc)

That is the physical view according to bus geometry if you will, and matches for instance what linux does with devices (see for instance /proc/bus). This provides a basic naming taxonomy. Hostmot2 does something similar btw. It is a good low-level structure to denote devices etc.

I'm not sure if the bus topology is a good application level naming of say pins, because then names carry type and geometry information which might be subject to change.

An example: assume you have several CAN interfaces (like many PC cards), and you'd mirror that in a pin name like rtcan0.4.ds302... which comes from interface, nodeID, device profile etc

Now move the device from bus 0 to bus1 - peng, all the pin names change, requiring a wholesale rename.

I would think it would be better to use a logical name for a device (like 'canduino1.something') not reflecting the bus topology because that decouples functionality from implementation method. And at some point you would associate the logical name with a bus geometry path. But if you now move the device, you'd just change that association, not all the names.

Also, from an application level perspective you'd really not care if a particular pin is imported by say a parport, or a bus device. So those are different concepts.

Note that the linux udev mechanism provides exactly that vehicle: it is a translation mechanism from bus geometry to logical name. For instance I have

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTRS{serial}=="DN001UBJ", SYMLINK+="cubox"

as an udev rule, and that gives me /dev/cubox - the serial console for one of my ARM playgrounds, regardless of the USBserial dongle make, hub, and port it is plugged in.

I'll describe how that can be done a bit later - but basically I'd see a busmaster as an instantiable HAL component which could support any number of devices of different profiles

if you connect a new bus device, you would do a 'newinst ', and the params part would specify things like nodeID, device profile etc. It would also tell the busmaster to start servicing this bus node, and it would create pins of this instance according to device profile and parameters chosen. In this example '' corresponds to 'canduino' from above.