Premise Weeder Technologies Digital I/O Module

[dinki]

Here's the new test results:

Testing Channel_B as Output. Clicked State True (first three entries). Clicked State False (last three entries)

[1348] Send: <AHB>
[1348] Raw Packet: [AHB]
[1348] Module ID: [A]
[1348] Send: <ALB>
[1348] Raw Packet: [ALB]
[1348] Module ID: [A]

I'm not certain, but shouldn't this be ABH instead of AHB? It looks like the format is Device_Module-Channel-State .


Testing Channel_A as Input. Opened door connected to Channel A(First two entries). Closed door connected to Channel_A(Last two entries).

[1348] Raw Packet: [AAH]
[1348] Module ID: [A]
[1348] Raw Packet: [AAL]
[1348] Module ID: [A]

PortSpy values are the same as the previous post for both Output and Input values.

 

[123]

...shouldn't this be ABH instead of AHB? It looks like the format is Device_Module-Channel-State ....

According to the WTDIO-M's datasheet (Table 2), the format for setting an output channel's state is:
ModuleID State Channel Time
where Time represents the time to hold the output in its new state before reverting to its previous state. In the WTDIO-M driver, this is represented by the AutoReset property.

What the data sheet does not mention is that an output state is reported in "ModuleID Channel State" format. I noticed this in the old Weeder driver and needed you to carry out a few tests to confirm it.

I noticed that transmitted commands are echoed by the module. I had coded the driver to disable echo when a WTDIO-M child object is created. I had not anticipated that WTNet might not be connected to a port when you are creating WTDIO-M child objects ... so the 'echo off' command never gets to the physical module. I've added code that runs when WTNet is initialized. It looks for all WTDIO-M child objects and sends 'echo off' to each corresponding module (see the InitAllModules method).

With this new version, I'd like you to have DebugView running from the moment that you instantiate the driver (i.e. when you run Device > CustomDevices > New > WTNet). I want to see all debug messages generated when you create a WTDIO-M child object, set its ModuleID, and when you set the Network property to a COM port.

This version parses the incoming data and reports it. Be prepared to see a few "Unknown Packet" messages.

Repeat the tests you've performed previously and add this one: turn off power to the module and then restore it. The WTDIO-M is supposed to transmit a special command upon startup and I want to see its exact format. I believe it should look like "A!", for module "A", and the driver will re-initialize the module.

 

[dinki]

On setting up WTDIO-M:

[1348] InitModule: <Sending Echo Off command>
[1348] Send: <AX0>
[1348] InitModule: <Sending Read All command>
[1348] Send: <AR>
[1348] Raw Packet: [A3FFC]
[1348] {Unknown: 3}

PortSpy output:

AX0
AX0
AR
AR
A3FFC

----

Test Channel B as output. Clicked State True (first entry). Clicked State False (last entry):

[1348] Send: <AHB>
[1348] Send: <ALB>
[code]

PortSpy output:

[code]
AHB
AHB
ALB
ALB

----

Test Channel A as input:

[1348] Raw Packet: [AAH]
[1348] {Unknown: A}
[1348] Raw Packet: [AAL]
[1348] {Unknown: A}

PortSpy output:

AAH
AAL

-----

Power failure/Power restore test:

[1348] Raw Packet: [A!]
[1348] {A was reset.}

PortSpy output:

A!

I did run into an error in doing this step. See attached image.

 

[123]

...Power failure/Power restore test ... I did run into an error in doing this step ...

Thanks for the screenscrape. The error is due to something I overlooked. I called the class "WTDIO-M" and it contains a hyphen. According to VBScript's naming rules for variables, you can only use alphabetic and numeric characters plus the underscore character ( a-z, A-Z, 0-9, _). In addition, the first character cannot be numeric. I've changed the class's name from "WTDIO-M" to "WTDIO".

The latest version of the driver (see attachment) has basic functionality and should let you set the outputs, and receive the state of the inputs, of one or more WTDIO modules. Give it a thorough test and please post your results.

Here are the features for the next version:

1. Sync on Connect
   Upon connection, the driver should synchronize the state of all its channels with the physical device. At the moment, it assumes all channels are false (i.e. Low) and this is a faulty assumption. It should acquire the state of each channel and set its Channel objects accordingly. At the moment, the driver transmits a Read command upon initialization but does nothing with the WTDIO's reply (a single hex number representing the state of several channels). I need to do some research on how to efficiently translate the hex number into something I can use to set the state of specific Channel objects.
2. Watchdog
   A Watchdog should poll the WTDIO module to ensure it is still connected to the PC. See this post for a complete description. I believe I can implement this feature without any difficulty.

 

[dinki]

Installed it from work and can only test the output channel. Working fine. Will test the input and power restore function tonight if all goes well.

The features for the next version look really cool. Can you tell me if you can add the ability to log state changes using the old logging addon module?

 

[123]

... if you can add the ability to log state changes using the old logging addon module?

The Logger module logs state changes for Home objects not Driver objects. You'll have no problem logging the activities of whatever Home objects you bind to the Weeder driver (i.e. DoorSensor, MotionSensor, etc).

Native drivers have the ability to log their activities to a *.log file in the "...\Premise\SYS\Log" folder. You'd enable a driver's log only if you suspect problems and wish to view its communications in greater detail. I don't plan to implement this kind of logging.

The Weeder driver is a Module therefore all of its VBScript source code is visible. If anyone wants to see how the driver operates, or add a few "debugout" statements here and there, they have complete access to the source code.

 

[dinki]

... if you can add the ability to log state changes using the old logging addon module?

The Logger module logs state changes for Home objects not Driver objects. You'll have no problem logging the activities of whatever Home objects you bind to the Weeder driver (i.e. DoorSensor, MotionSensor, etc).

Oh yeah.. I did know that. I guess it's a typical Monday. Thanks for the explanation.

 

[dinki]

I started to do some testing and am running into a problem. I've noticed this problem before but it seemed to correct itself so I hadn't mentioned it. The problem I'm having has to do with what I can only guess is the initialization of the board. The old version of the addon module sends a bunch of commands to the board which I can only assume is setting the different channels as either inputs or outputs. I would guess that this needs to be done an time the device is booted/reset (A!). With the current add on module, I am unable to receive inputs on the board (at least on the one channel I have the switch connected to). After I deactivate your add on module and enable the old one, it then sends commands to the board and I can then use your module until the board is reset.

As you may remember, I am using a program called Virtual Serial Ports Emulator to do a serial port redirection from my home theater pc to my desktop running Premise. I've noticed that sometimes not all of the old add on modules initialize sent commands make it to the board. This is pretty hit-and-miss. I've started a thread on the VSPE forum in hopes to figure out why this happens. If you do add the initialization to your module, can you some how add a slight delay or listen for a response (if the board returns one) before sending the next channel's command to set it as either an input or output?

Please note that I am making some assumptions as to what the old module is doing as far as initialization goes but I'm pretty sure it's necessary.

 

[123]

...running into a problem ... I can only guess is the initialization of the board. The old version ...sends a bunch of commands ... assume is setting the different channels as either inputs or outputs....

... can you some how add a slight delay or listen for a response (if the board returns one) before sending the next channel's command to set it as either an input or output?

Thanks for that information. Yes, upon startup, the old Weeder module sets all 14 channels as Inputs ("Switch"). Interestingly, the documentation indicates that upon power-up, the WTDIO automatically sets all of its channels as Inputs. However, if that were true, there would be no need to have the driver initialize the channels. Yet, real life indicates initialization is necessary! OK, I'll add channel initialization code to OnChangeOnInit ... only the Channel objects will be set as Inputs upon initialization.

The old Weeder module used a WaitTime of 80 ms (the time delay between successive data transmissions) and the new one uses 200. If that isn't long enough for VSPE, change it in WTNet's ClassConstructor. At this point in the driver's development, I'd rather not build a confirmation mechanism for every command sent to the WTDIO.

 

[dinki]

Thanks for the info on WaitTime. I set the old module to 200ms and now I'm able to initialize without any dropped channels. I look forward to the next version of your version. Thanks again for putting in all this time working on it.

 

[123]

The latest version attempts to address initialization and channel states.

1 - WTDIO Initialization
Upon initial connection (or a WTDIO restart), the driver instructs the WTDIO module to:

1. Suppress command echoes.
2. Program all Input Channels as "SWITCH" inputs.
3. Requests the state of all channels ("READ" command).
4. See the InitAllModules method for details.

2 - Handle replies to a READ command.
The WTDIO's reply to a READ command is used to set the state of all Channel objects.

What does this mean for you?

• The WeederTech driver should initialize the module upon connection; there should be no need to use the old Weeder driver for this purpose.
• After the WTDIO is disconnected and reconnected, the driver should correctly report the state of each channel .

Here's how to test these new features:

1. Connect the WTDIO (i.e. set the Network property to the appropriate COM port) and set input channel A to high then low and back to high. The driver should reflect these state changes correctly to the Channel_A object (Channel_A's state is now "True").
2. Disconnect the WTDIO (i.e. set the Network property to nothing) and set input channel A to low. Reconnect the WTDIO and confirm that the driver sets the Channel_A object to "False".

 

[dinki]

Here's how to test these new features:

1. Connect the WTDIO (i.e. set the Network property to the appropriate COM port) and set input channel A to high then low and back to high. The driver should reflect these state changes correctly to the Channel_A object (Channel_A's state is now "True").
2. Disconnect the WTDIO (i.e. set the Network property to nothing) and set input channel A to low. Reconnect the WTDIO and confirm that the driver sets the Channel_A object to "False".

I'm not sure if I'm doing something wrong, but I am unable to changle the DigitalInput State either while connected to the comport or disconnected from it. When I click on the box nothing happens.

 

[123]

... I am unable to changle the DigitalInput State ...

That's correct; you cannot change the DigitalInput class's State property (it is Read-Only). It is used to model the state of an external sensor like a door contact switch or a motion detector. Toggling the DigitalInput's State property would imply you were trying to change the state of the contact switch or motion detector and that is impossible. That's why the State property is read-only.

In the driver, if you specify that Channel_A is an Input, the driver sends a command to the WTDIO instructing it to treat its "A" channel as an input. Using a paper-clip, if you connect/disconnect channel "A" to ground, the driver should reflect these changes in the Channel_A object (i.e. DigitalInput's State will toggle True/False).

 

[dinki]

Oh, I misunderstood your instructions. I didn't realize you wanted me to use the physical input. Will try tonight.

 

[123]

No problem. It is difficult to describe this stuff without causing confusion (i.e. did I mean to say the driver's channel or the WTDIO's physical channel?).

FYI
Post #18 of this thread contained the following debug message:
[1348] Raw Packet: [A3FFC]

This message ("A3FFC") was the WTDIO's response to a READ command. "A" is the Module ID and "3FFC" represents the state of all WTDIO channels. If you convert 3FFC into binary you get a 14 bit binary value, "11111111111100", where each bit represents a channel's state. The documentation indicates that the Least Significant Bit (LSB) represents channel A. That means the right-most bit is channel A and the 14 channels are listed in reverse-order.

NMLKJIHGFEDCBA
11111111111100

If I've understood the documentation correctly, during the test you had performed (that generated "A3FFC"), channels A and B were low and the balance were high.

Keep this in mind when testing the driver. If after disconnecting/reconnecting the WTDIO you see weird stuff like the Channel_N object being True instead of Channel_A ... then I've got the whole thing backwards!