Hmmm. Interesting idea to just have coils and registers presented as pins. Then you'd only need to specify how many of each you want to access, along with the base address. It gets more complicated if you need to allow access to registers/coils in multiple discontiguous ranges.
There's also a problem with multi-register values. Some devices can handle 32-bit values, which are generally composed of two 16-bit %Rxx values. I'm not sure if the spec tells you to use a certain endian-ness, so it may be necessary to be able to specify that as well. This is why I was thinking about a higher level spec for specific devices (ideally with a low-level core that's at least from common source code, and at best a single shared module). It would be much more readable in HAL to have a modbus.0.vfd.0.spindle-speed pin rather than having something like the inverse of a scale block to convert from float to whatever integer units the VFD uses, then possibly to split that into two 16-bit words for connection to modbus.1.register001 and modbus.1.register002. It would also be possible now that I think of it, to have a VFD module that converts from "engineering units" to whatever registers and coils the modbus interface provides. The downside is that you end up with a lot of HAL connections that aren't really useful, and can cause major problems if they're screwed up (imagine the oops of swapping the high and low words of a spindle speed, for example). The communications parameters you mentioned look as though you have in mind only a single device per serial port. I think what you need here is a port specification per serial port (baud/parity ...), and a "port + address" spec for each device. Since modbus can handle multiple devices per serial port, it would make sense to have that capability in the driver. I should stop thinking about it, because it keeps getting more complex the more I do :) - Steve Kirk Wallace wrote: >Below is a beginning of a first pass at writing an EMC Modbus RTU >interface spec. Any comments are welcome. > >" >EMC should talk to Modbus RTU devices through a Modbus RTU component. >Each device, hence Modbus address, would have a Modbus component >instance, modbus-rtu.0, modbus-rtu.1, etc. For example, a spindle or >tool change signal might have an HAL link of "net motion.spindle-on >modbus.0.coil001" and "net iocontrol.0.tool-change modbus.1.coil003". If >a device meets modbus standards, no device dependant driver would be >needed. Each modbus instance would need parameters set for; serial port >number, address number, baud rate, parity, number of stop bits, latency >time, response time-out, etc., to match the characteristics of the >device being attached. >" > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
