next »

[miked]

We installed 35 Viconics stats on an ALC network. Everything went fine until we tried to get all the information on the front end. The stats will not go online unless you re-download memory the the ALC module, which re-initializes the communication port. The stats will then stay on line for a maximum of 4 hours, after that you lose all the information. The stats are contolling fine as stand alone, but we must get to information on the cusomers computer, and have it be reliable. We are out of ideas. If anyone has any ideas, would you please enlighten us.

[Zinc22]

Hi Miked,

You are at the right place to get things fixed.

A few questions first.

- Speed used ?
- Network topology. I.E. multi-trunk, single trunk ?
- Network wire length.
- EOL installed ?
- Through an LGA I assume ?

Can you please explain what you mean by:

re-download memory the the ALC module

?

Can you please expand on:

after that you lose all the information

? Is the device still online ? Is it some points you cannot read ?

[DV8]

Hi,

It sounds like your problem may stem from badly configured software. Have you taken a look at the Integration demos? They take you step by step into the correct installation of the devices.

Here is the link: http://www.communicatingthermostat.com/tutorials.htm

Simply log in and watch the video. It was greatly helpful to me!

DV8

[Qwerty]

Hi Miked,

"Everything went fine until we tried to get all the information on the front end. "
Can you expand on this also ? Are you using graphics or the network tree to view the objects/devices ?

Also, is the LGE/LGR writing in any objects of the Viconics' devices ? (Occupancy, Setpoints)
Or is there any trends that are pulling values from the stats ?

I've had 50 viconics' devices on a 5000 ft network hooked up to a LGE 2Mb and I was able to see all the devices (and their objects) through a 3rd party front-end.

Keep me updated please.

Qwerty

[miked]

Thanks to all of you that responded to my posting!!  Here are a few details of the installation and where it stands now.  I split my original network in half with 18 stats on the first network with a length of 100'.  This network was hooked to an LGR25.  The second network has 16 stats with a network length of 1500'.thisnetwork is hooked to an LGR1000 and has a repeater between the LGR and the first thermastat.  The LGR's are set to run at 38400.  I have tried different combinations of shielding and terminating.  The best results seem to be when I leave the shield off and do not terminate.  I have been adjusting the APDU timeout settings and the best results seem to be with the LGR25 set at 7500 and the LGR1000 set at 4000.

I have all of my control programs residing in the LGR1000.  I am only addressing network points for room temperature, fan, heating 1, cooling 1, and suppy air temperature.  My only goal is to be able to show an equipment graphic and be able to use the zone color on a floor plan graphic.  I am not trying to write setpoint or other values to the thermastats.

What seems to be happening now is that if I download memory to the LGR's I get thermastat values coming in after about 10-15 minutes.  If I leave the system alone after a few hours the values fall off and the network points say the device is off line or in some type of read error.  If I download again the values come back in.  On Monday I enabled a static binding perameter in the ALC software.  The next morning when I check the system, I had values that held but it appeared that the values had not changed and that the stats were off line again.  I repeated the process yesterday and this morning it looks like all of the stats are on line and that values have changed overnight.

I think by splitting the networks in half, I have eliminated wiring issues since all of the stats are coming in and the network light at the stats say they are on the network and talking. Both networks seem to be reacting in the same way.  I don't seem to lose one network and keep the other.  ALC has looked at bacscopes of the network and indicated that an outside air temperature is broadcasting too much but this is on the arcnet and doesn't seem to effect it's communication and nothing on the MSTP network is asking for this value to my knowledge.

I hope this sheds some light on the project.  I'm making progress but it's painfully slow!!

[Qwerty]

Hi Miked,
 

I would first suggest that you add another vendor's MSTP device to the network (ALC for example) and see if the behaviour of the network is the same.

Also, I would suggest that you set the APDU Timeout Settings to 10000 msec and set the Number of APDU Retries to 3 (at least) at both the LGRs and WebCRTL level. Default values at the WebCTRL interface is 2000ms with a retry value of 0. This means that if the front-end don't get a reply to one of its request, the device will be considered offline after 2 seconds.

Setting these properties as mentioned above might prevent some device from dropping offline.

Would it be possible to send me some packet capture (with the BACscope or BAS-o-matic) ? That would be helpful. email is : frichard@viconics.

One last thing: the cable shielding should be tied through at every device (floating and not connected to the Ref port of the BACnet module) to make a continuous shield that runs the whole length of the segment.
And each complete segment should have a single point tied to ground.

Keep us updated as soon as possible !!!

[Zinc22]

Regarding shield.

I suspect this is not related to the issue but still important to know and good practice to do.

[DV8]

Miked,

Haven't heard any news from you. Did you manage to resolve this issue? If you did, please let us know what you did. I think it would help others here to know a little more about it.

Thanks

dV8

[miked]

Communications are much better.  All the thermastat room temperatures have held in for over a week.  I still loose some of the other values from the stats but I have an early rev # on the communication boards so Viconics is shipping the latest version that can handle larger commmunication packets.  I think the thing that had the biggest effect was slowing the APDU time outs in WebCTRL to 10000-12000 from the default of 2000.  Hope this helps you in the future.

[DV8]

Hi Miked,

It's good to hear that you are getting somewhere with your problem. Please let me know how the boards with the most recent revisions work for you. My bet is that they will solve the problem completly.

Keeping my fingers crossed.

Dv8

[Zinc22]

Glad to hear Miked.

Please keep us posted.

[miked]

I changed the communication boards yesterday and after a few tense moments when I lost all comunication and could not get it back everything went well.  I got on with tech support and they found that the new boards changed the MAC address by adding a VT to the start of the thermastat name.  I had to go into sitebuilder and delete the original "discovered networks" and do a new search.Thanks to all for your help!!

[Zinc22]

Glad to hear everything is up and running.

Anytime you have an issue, please just let us know.

We'll do our best to help out.