More Viewstat Module Trouble

TurnipTruck

Greetings again. I am still having some troubles with this pesky system. At startup, the module is skipping waits between broadcast commands for retreiving current values from the stats.

Attached is a text file showing notifications from my system where I am having trouble with Viewstats. I am watching strings being sent to the physical Viewstat device and strings coming from the virtual Viewstat device for easiest understanding.

Notice for example on line 35, a broadcast command is sent for all stats to report their cool setpoint, the module then waits for all of their responses on lines 36-52, the module then moves on to the heat setpoint on line 53.

Now if you look at lines 91-93, the module sends the broadcast commands for current humidity, humidification setpoint and dehumidification setpoint immediately one after another with no time allowed for responses. Herein lies the problem. There should be a wait between each of these broadcast commands allowing the stats to all respond as was done in my first example.

I don't know what I could have done to cause this as all code relating to this exists in the pre-compiled COMM file provided with the module.

Thanks for any help.

alexanbo

Is the system not working as you expect it when you actually try to do something?

I wouldn't put a huge amount of stock into the timing of the feedback from the virtual device. Diagnostics isn't quite a real time reporting tool, I've sent a burst of data to a device and notification will keep going long after the strings have been physically sent out.

TurnipTruck

alexanbo wrote:

Is the system not working as you expect it when you actually try to do something?

I wouldn't put a huge amount of stock into the timing of the feedback from the virtual device. Diagnostics isn't quite a real time reporting tool, I've sent a burst of data to a device and notification will keep going long after the strings have been physically sent out.

The system is not working as needed. For example, if a stat does not report with a cooling setpoint during bootup, the module will not allow you to change that setpoint once online.

The data in my notifications log is correct. I am able to verify the data going in and out of the serial port to the thermostat bus.

alexanbo

I didn't mean to say that the data from notifications was incorrect, just that I wouldn't trust the timing on it. For example the block of notifications where you're having problems, there's the lines with T-1 HVAC stuff. That's all generated from one string from the T-Stat so that having to output all the different parameters from the virtual device makes the device notifications non real time. In fact thinking about it, notifications from two separate devices might not be synced up with regards to time at all.

TurnipTruck

Having looked closely at the data, the info and the timing is correct. Each thermostat parameter is a seperate string from the stat. They are polled for a value and all respond one at a time, then the next poll occurs based on a polling delay determined by how many stats you tell the module you have at startup.

vining

That below might be ok. That's only four command in a one second period and the Aprilaire T-Stat have several different timing requirements.

Line 89 :: String To [5001:1:8]-[SN F?$0D$0D] - 09:22:51
Line 90 :: String From [33001:1:8]-[T-1 FMODE-AUTO] - 09:22:51
Line 91 :: String To [5001:1:8]-[SN HUM?$0D$0D] - 09:22:51
Line 92 :: String To [5001:1:8]-[SN SHUM?$0D$0D] - 09:22:51
Line 93 :: String To [5001:1:8]-[SN SDEH?$0D$0D] - 09:22:51

Aprilaire Programming Manual:

Allow no less than 265 milliseconds after issuing a command (explicit or global) before issuing a second
commandt o the samet hefDlostatw hen no responseis to be received( i.e. CR=QUIET or CR=SILENT).
Commandst o different thefDlostatsm ay be issuedw ith no lesst han 20 millisecondsb etweenc ommands.
If you use nothing more than the StatNet command set (revision IB), the time between commands to anyone
thefDlostatc an be 20 milliseconds. New Aprilaire commandsc an be up to 32 charactersin length and may
require more processingt ime, so, as a generalr ule, 265 millisecondss houldb e allowed.
The following are the most common StatNet commands (see Command Set for details on each command):
MODE, FAN, TEMP, REMOTE, HOLD, SH, SC, CI-C8 and CR
2. Allow no lesst han 265 millisecondsa fter issuinga n explicit (specifically addressedc) ommandb efore issuinga
secondc ommandt o the samet hefDlostatw hen a responseis desired( i.e. CR=NORMAL).
Actual time required for consecutivec ommandsto the samet hefDlostatis 330 milliseconds. Therec an be a
differenceb etweent he progran1medtim e delay and actualt ime delay dependingo n the software/hardwareu sed,
so 500 milliseconds will allow for some variation.
3. Allow 265 millisecondsb etweenc ommandsto different thermostatsw hen a responseis to be receivedf rom all
thefDlostats.A llow 20 millisecondso f no responseis to be received.
4. Allow no lesst han (265. "No. of Thermostatso n the Network") millisecondsa fter issuinga global command
before issuing a secondc ommandw hen a responseis desired( i.e. CR=NORMAL). Roundu p to the nearest
second.
Roundingu p will allow for somev ariation betweenp rogrammedti me delay and actualt ime delay. Some
experimentationm ay be requiredt o ensuret he minimum time betweenc ommandsis respected.

I would post the whole PDF but it's to big. If you don't have this reference you can find it on the AprilAire web site or if you'd like I could email it to you.

Are you using the new Duet module?

TurnipTruck

Lines 91-93 are broadcast commands that should ellicit a response from each thermostat. The module should be allowing time between each command for all of the thermostats to respond, instead it shoots out those three commands immediately one after another. After another reboot, the line 91-93 commands may delay properly where other broadcast commands will lack the delay.

DHawthorne

I hate to put it in these terms, but your problems seem to be with the module, not the stats themselves. I've only used the AMX modules once, and that was with a job that only had one stat; other than that, I have only used my own code, and on the control side I have not had any problems with them. Hardware issues, yes ... but once those were sorted out, programming has been fine.

TurnipTruck

Hi Dave,

What sort of hardware issues have you had?

DHawthorne

TurnipTruck wrote:

Hi Dave,

What sort of hardware issues have you had?

I responded in the other thread ...