FX40 Scheduling problem.

[aztra]

Can anyone lend any advice as to something I may or may not be setting in my schedules. I have several FX40’s ( Ver- 3.0.106.1) where the schedule firing is erratic at best. When I fist build them they seam to work, however before long they just seam to freeze up. As an example, looking at the schedule my state should be false however the output is true. I can’t even seam to force them to false without rebooting the fx.

Thank you

[Chris_Worthington]

Have you tried a force read/write on the point in question?

What field device and protocol do you have the problem on?

[freddy-b]

Have you checked the apllication director for any weirdness?

[BACnet Jeff]

Sorry, we do not currently have an answer but it sounds like we may be having the same issue.

For us this seems to happen in the morning when the units should enter the occupied state, but they never do. It's very intermittent, we never which building is going to act up next (or when).

This project has 27 buildings and each building has an FX-40 connected to N2 devices. Some of the FX-40’s also have BACnet MS/TP devices connected to the RS-232 port via a B&B RS-232 to RS-485 converter but these buildings act up very little so we don't think it is related.

Have you noticed if the CPU capacity is maxing out at 100% when this happens? We are not sure but suspect it may be related.

[freddy-b]

Have you noticed if the CPU capacity is maxing out at 100% when this happens? We are not sure but suspect it may be related.

Ya, I would say thats related. Nothing but bad news if a 40 gets overloaded.

[BACnet Jeff]

Thanks for the info!!!
We are planning on removing all trends on Monday norning. Do you think this could help?
Any other things to look for?

[BACnet Jeff]

AZTRA,

We reduced the N2 trunk polling to 1 and 1/2 minutes. (think the factory default was around 5 sec.) and the CPU usage value droped like a rock. the 1st building was running at 60% and after the change it was only 17%. We did it this morning so we still don't know if it corrected the schedule issue but we are hopful.

I'll let you know how it goes.

To Freddy B,

Thanks, 4 the heads up about keeping the CPU usage below 80%.

[aztra]

I haven't replied as I've been swamped. I like this overloading angle as I notice it only occurs on the FX40 that are being well utilized…

[aztra]

Have you tried a force read/write on the point in question?

What field device and protocol do you have the problem on?

Chris,how can I automate a forced read/write? I have a FX16 where a lon point occasionaly locks up. To fix it I manualy force it off then back on. then all is ok for a month or so.

[BACnet Jeff]

Follow up on extending the polling times:

Even though the CPU usage has droped by and avgerage of 3/4 at each FX-40 the schedule issue still exist.

The CPU usage still goes to 100% in the morning. It is random as to which FX-40 is going to be effected next.

Example:
We watched a building run steady at 16% CPU usage during the day. In the morning it was at 100% and didn't follow the schedule change to occupied.

BTW...How did the force Read/Write go, any success?

[BACnet Jeff]

When I fist build them they seam to work, however before long they just seam to freeze up.

Same thing here. Time apears to be the only common factor.
After a while the schedules get weird. Rebooting clears the error but once it happens it often comes back soon, over and over.

[sysint]

Follow up on extending the polling times:

Even though the CPU usage has droped by and avgerage of 3/4 at each FX-40 the schedule issue still exist.

The CPU usage still goes to 100% in the morning. It is random as to which FX-40 is going to be effected next.

Example:
We watched a building run steady at 16% CPU usage during the day. In the morning it was at 100% and didn't follow the schedule change to occupied.

BTW...How did the force Read/Write go, any success?With the scheduling is there some sort of expected response from the devices? If so, maybe you can stagger your start times by a few minutes each and see what happens then.

[checkvalve]

There was a bug found in the j2se, I believe something to do with the java.util.calendar package. This can cause a date to be miscalculated and typically manifests itself with either schedules not calculating the next event time correctly or with history collection triggers not calculating the next trigger times correctly.

I believe that there is a patch available for the baja.jar for all builds affected, which was 3.2 and older and only on embedded jace stations. This doesn't affect stations running on pcs like a web sup or soft jace.

Contact your tech support channel and they should be able to provide you with an patched jar that fixes the issue.

When this is the issue your schedule would show unoccupied and the next event time would show the next day instead of the current day. Even though the current time on the jace should have made the schedule output be occupied.

If this doesn't sound like your actual symptom then you may have something else going on. In which case you should probably contact your tech support channel anyway.

[BACnet Jeff]

With the scheduling is there some sort of expected response from the devices? If so, maybe you can stagger your start times by a few minutes each and see what happens then.

Thanks, we'll look into this but many of these FX-40's have only 1 DX-9100 connected and only 1 schedule.

This is why we are so suprised that they are overloading the CPU usage.

[aztra]

Have you tried a force read/write on the point in question?

What field device and protocol do you have the problem on?

I've installed the latest updates.. being as intermitent as it is, it's taken a while to get back to this thread.

If I look at the commanded point it will read "LogOn" however it's off. If I do as you suggest and force a read/write the unit will start.

Is there an option in the lon settings to force multiple writes or at least some way to verify if it's really written?

[Chris_Worthington]

I've installed the latest updates.. being as intermitent as it is, it's taken a while to get back to this thread.

If I look at the commanded point it will read "LogOn" however it's off. If I do as you suggest and force a read/write the unit will start.

Is there an option in the lon settings to force multiple writes or at least some way to verify if it's really written?

I dont beleive there is way with standard objects to, for example link an interval trigger to the force read/write :(

IMO I believe it has something to do with the status going through as "overridden" during a "setpoint" or anything other then the "set" command thats screwing things up, due to it "not" releasing the override.

I don't believe JCI has their drivers parsing properly, personally I gave up on the flipping things and ripped them out :D

Perhaps someone else will chime in here with this new information you have provided and give you a better answer then I.....

Chris