On Sun, 2008-01-27 at 15:53 -0500, Stephen Wille Padnos wrote:
> 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).
I didn't want to have any device dependent features in the Modbus RTU
component. I was hoping that that would be up to mixing other components
to get the data into the proper form. The Modbus RTU component would
only handle assembling the packet, managing the communications protocol,
and handling communications errors.
I am using the my VFD manual as a guide, and all of its registers are
eight bit. For 16 bit parameters, it uses two register addresses and no
floating point, such as:
Func- | Name | R | Description | Reg- | Ra- | Res-
tion | | / | | ister | nge | olu-
Code | | W | | | | tion
----------------------------------------------------------------------
D007 |Scaled output frequency | R |Displays the | 0011h | 0 to|.01-
(high) |monitor | |output freq..| |999- | Hz
| | | | |999 |
-------- ----- -------------------
D007 | | R | | 0012h | |
(low) | | | | | |
| | | | | |
----------------------------------------------------------------------
So for this example, an HAL component would be needed to reassemble the
two registers into a u32, or whatever is needed. I have no idea of the
range of Modbus device configurations, I was hoping this VFD would be a
typical 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 intended to have multiple devices on each serial port. I was thinking
that the communications parameters might have to change on-the-fly for
each device on the same serial port.
> I should stop thinking about it, because it keeps getting more complex
> the more I do :)
>
> - Steve
My brain is is hurting, too (easy to do though).
--
Kirk Wallace (California, USA
http://www.wallacecompany.com/machine_shop/
Hardinge HNC lathe,
Bridgeport mill conversion, doing XY now,
Zubal lathe conversion pending)
-------------------------------------------------------------------------
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
