Siemens System 600 Driver skipping points


#1

We are using (2) JACEs on a building network and are having issues with the Siemens System 600 / Apogee Driver skipping 5/22 points on each of the (7) “Cabinets”. Upon activating the Debug Mode and monitoring the Application Director the output displayed that 5 of 22 points are being skipped and no Point Log Report is being initiated for these 5 points on each of the 7 Cabinets. This seems unusual since the points were originally discovered by the driver but since have stopped updating which was confirmed by monitoring the Application Director output.

We have tried increasing the interchar delay to 50ms, increasing the timeout from 5,000ms incrementally up to 60,000ms, rebooted the JACE(s), forcing the update action on the points and also tested using batch polling but without success. Any way to get these points to update since they were originally discovered by the driver and just stopped updating?


#2

Can you provide the current Niagara and driver version you are using?

If you attempt a discovery again, do those points return in the response?

Do you know of any recent changes that have occurred on the network and or device configurations before these points stopped polling?


#3

Baja Version: Tridium 3.8.38
Model: NPM3
Niagara Runtime: nre-core-qnx-ppc (3.8.38)
csisys600 Installed Version: CSI3 3.8.38

When executing a discovery again (We agree with this test and we tried this earlier) no results are populated and the job never prompts a “failed” or “complete” prompt, instead the progress bar just hovers at approx. 15% for several hours.

Several Cabinets were deleted from the AX JACE network once a new N4 JACE was installed so that 2 JACES monitor the Cabinets in an effort to reduce the workload of the AX JACE since we have been having issues with the AX crashing due to low Java Heap that degrades over time.

It’s curious that the discovery never completes and the progress bar just hovers. The N4 JACE does not share the issue of points being skipped but it is also experiencing the issue with Low JAVA Heap, according to Tridium they feel that the driver is “leaking memory”. We see the N4 JACE operating with 4MB of heap free and after executing garbage collection the heap only increased to 5MB of free heap.

Baja Version: Tridium 4.4.73.24
Model: TITAN
Niagara Runtime: nre-core-qnx-armle-v7 (4.4.73.24)
csisys600 Installed Version: CSI3 4.0.22.16


#4

Does this mean you now have two competing Niagara stations communicating on the same serial network to the system 600 devices? Or are these devices now on separate physical networks?


#5

We have (2) JACEs interfaced with (2) Siemens MEC controllers, the (2) Siemens MEC controllers are Diasy Chained on the same P1 network field buss (same physical network) with additional Siemens MEC controllers.


#6

I’m not entirely sure that architecture is going to work out. You will likely need to separate the two JACE’s physical network as there is likely going to be a lot of data collisions with that type of multi-master configuration. This assumes a serial network and not an ip network so if that’s not the case, let me know so we can continue to troubleshoot your issue.


#7

The network is connected to the JACEs via serial connection.

When I follow the “Trace” entries in Application Director (once enabled via the Spy Logs) we can see the points that are discovered by the JACE being polled although some points are being skipped. We can also see the points in detail being skipped when Debug mode is enabled. We do not see any cabinets discovered by the other JACE being polled.

From our understanding this driver acts as a human typing commands via hyper-terminal and then “scrapes the screen”. This sounds like pseudo peer-to-peer communication since only the desired Cabinets and points appear to be polled and not the entire network from what we can tell by monitoring the Application Director but please correct me if this is wrong. Thank you.


#8

You are correct in how the driver communicates. I do have my suspicians that there is data clashing with both of these JACE’s attempting to communicate on the same physical network. I would recommend to verify this to disable the network in the N4 station and then see if the AX JACE begins communicating again. If this resolves the issue, then this tells me the two systems cannot be on the same physical network and must be isolated.