Re: Memory and Modbus

  • Thread starter Lynn August Linse
  • Start date
L

Thread Starter

Lynn August Linse

At 10:58 PM 1/8/00 +0000, you wrote:
>The Modbus map I am doing is a struct of arrays grouped by type, digital ins are unsigned short as are digital outs. The modbus holding registers and some other feature registers are Unsigned
int. Analog ins, highs and lows are float and there are some other misc types.<

The memory design depends on your goal I guess. If one has a few I/O but needs blinding speed your pick a different design that someone who wanted to mash through 5000 I/O each second looking for alarm conditions and also different than some one who is doing a high-level vision processing system.

Well, my suggestions:

1) the map and the I/O reality should be 100% separate. The idea of a new map for each "rack" is bad - some PLC do that and upgrades are a nightmare sometimes even requiring an edit of the program to adjust i/o addresses. The I/O data should be merged into the memory by some map scheme implemented by the driver. For example, if your Opto-22 inputs 16 digital bits and outputs 16, you should have some table (in the driver) which maps these to some/any location in your working memory. The inputs could go to dio[23] and outputs to dio[245]. A bit like Modicon's "traffic cop" which moves data in/out of memory.

2) As for the 16-bit 32-bit trade-off. Considering the network/wired nature of automation today - I'd just stick to the traditional 16-bit since 99% of your remote datacomm will assume 16-bit registers. But I don't think going 32-bit would REALLY cause a great problem - just a lot of split/merge to
talk to the common 16-bit world outside.

3) I'd just implement the data as one or more simple arrays - such as:
ushort dio[MAX_DIO]; and float aio[MAX_AIO]; The PLC program shouldn't need gaps and remote datacomm can add gaps by using a mapping scheme.

4) For tags and all other "object" like attributes, I'd somehow layer them indirectly. In other words aio[17] is the 18th analog value, and a call to aio_GetTag(17) returns the tag name string of the same. This allows different users to track different attributes as required. If you don't support an attribute you could allows have a dummy null return or #define the calls out.

I think any attempt to create a master "analog_io" structure to satisfy every user will result in a big empty structure - some HMI have 300 to 500 byte structures for analogs just to fit all the possible alarms and tags and status in to support all of their possible settings. This is a powerful abstraction method, but had to manage by a single organization, let alone
diverse open-source programmers.

Lynn August Linse, Snr App Prod Engr
[email protected]
direct: +1 949-450-7272 cell: +1 949-300-6337

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Lynn August Linse:
> 3) I'd just implement the data as one or more simple arrays - such as:
> ushort dio[MAX_DIO]; and float aio[MAX_AIO]; The PLC program shouldn't need
> gaps and remote datacomm can add gaps by using a mapping scheme.

Yes, though I don't think any user program should see them. Any "public" interface should encapsulate them in function calls or in whatever is appropriate for the language in question.

Oh, and it would be good to allow gaps. So that the implementor can have some sort of Dewey decimal system to the array.

> 4) For tags and all other "object" like attributes, I'd somehow layer them
> indirectly. In other words aio[17] is the 18th analog value, and a call to
> aio_GetTag(17) returns the tag name string of the same. This allows
> different users to track different attributes as required. If you don't
> support an attribute you could allows have a dummy null return or #define
> the calls out.

Often enough, I suspect, the data should really be stored in different modules anyway. Partly because that's where they belong, and partly
because you might want to have two HMIs running simultaneously.

(Besides, buffer overruns in the HMI shouldn't be able to kill the controller.)


Jiri

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top