Private device variables for I/O types


patrickokeeffe

Recommended Posts

After perusing the manual and forums, I'm still a little confused about the private variables available in user-defined protocols. Examples from the serial comm chapters mention strDevice which I have used successfully but there should be more right?

I'm trying to update my protocol to recognize different device numbers. Right now, it simply listens and upon receiving a line feed (\010) checks to see if a streaming flag is high; if so, my parsing function reads the buffer and adds values to appropriate I/O types. I think DeviceNumber is what I want but none of the variables listed below are accessible to my parsing function: a "? DoubleToStr(DeviceNumber)" results in C1000 errors.

Here's a list I found in the description for I/O types. I added in parenthesis the column name the variable would correspond to in the Channel Table view, if any.

  1. DeviceNumber (D#) - the device number of the channel
  2. Channel (Chn #) - the channel number of the channel
  3. Specifier (Quick Note / Special / OPC) - the quick note / opc specifier for the channel
  4. SetToValue - the value to set to (output I/O types)
  5. strSetToValue - same as above, but the string version
  6. OriginalValue - the pre-converted value to set to. Return this for output I/O types.
  7. strOriginalValue - same as above, but the string version
  8. ChannelName (Channel Name) - the name of the channel

There's another list which includes strDevice from the section on Channel variables but it's not clear which, if any, of the others can be accessed in raw protocol file script.

  1. strDevice
  2. DeviceNumber
  3. strIOType
  4. Channel
  5. Timing
  6. Offset
  7. HistoryLength
  8. PersistAmount
  9. ModbusRegister
  10. HistoryInterval
  11. strConversion
  12. Broadcast
  13. BroadcastInterval
  14. Average
  15. strSpecifier
  16. strQuickNote2
  17. strNote
  18. strGroup
  19. strEvent

There must be a difference in scope between I/O types and Functions? The examples I followed recommend keeping large parsing routines in a separate function, not the OnReceive, but regardless of which function it is, DeviceNumber is inaccessible. What changes must be done to incorporate device numbers?

On a related note, my device's address is limited to 1 character but it's alphanumeric (0-9,A-Z,a-z) so if I choose to use DeviceNumber, I probably lose addresses A-Z,a-z? I can't imagine ever needing these but in the interest of healthy code, should I consider using the Specifier instead? That wouldn't be a problem as long as its easy to load a default "0" if needed.

pWXT510.ddp

Link to comment
Share on other sites

The first set of variables, include DeviceNumber, are only available in user protocols if you add a new I/O type to the protocol. That's because new I/O types are the only thing that can be directly attached to a channel. OnReceive isn't attached to a channel, but rather to the protocol.

The second set of variables are member variables of the channel and can typically be accessed by doing:

mychannel.deviceNumber

which will return the device number of the channel named "mychannel"

However, what I think you want, since you are using OnReceive, not an I/O type is "channel.addvalue()", which allows you to pass variables in to specify where the data should go, instead of mychannel.addvalue() which would add a value directly into a channel named "mychannel". Note channel.addvalue() is exactly that "channel", which refers to the list of channels, and addvalue() which is a member function of the list of channels object. Look in the users guide for the parameters, but it basically takes D#, I/O types, etc. plus the value.

As for your device address, I'd probably just encode the letters, so 0-9 is still 0-9, A-Z is 10-35, etc, or to make it easier, just do 101-126 for A-Z and 201-226 for a-z. It really doesn't matter how you map it. Using specifier is a bit less friendly.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.