Internet PLC Forum

We have checked with engineering and what Gary has suggested is correct. The CPU periodically tried to update its RTC (both calendar and time registers) by loading the data from battery-backed RTC on the FRAM-RTC board as it has a more accurate crystal. In the older firmware the update occur during the hourly crossover from xx: 59:59 to (XX+1):00:00.

Unfortunately if the updates occur during the midnight crossover (from 23:59:59 to 0:00:00) when the calendar date also change, then a race condition could occur such that the FRAM-RTC may still have the previous day date during the RTC update but after the RTC update the clock already passed 0:00:00 and the calendar date was not incremented. The date will be corrected after another RTC update.

Engineering has modified the firmware since r82B to avoid such a scenario so PLCs with firmware >= r82B should not experience this issue. Your PLCs vith firmware r82A unfortunately are still running the old firmware. Also for firmware before r83 they can't be field upgraded by users so if you wish to upgrade please contact support@triplc.com to arrange for RMA.


There are however some workaround we can suggest as follow:

If your PLCs  do periodically update their RTC from internet time server, then you may not need the RTC to be updated from the backup RTC every hour. In that case you can simply disable the hourly update of the CPU's RTC from the backup RTC. This can be achieved using the following statement once:

   SETSYSTEM 253,2  ' disable hourly update from backup RTC

The backup RTC will still function to load the CPU's RTC when the PLC is power ON. The backup RTC values is also updated simultaneously when you synchronize the CPU's RTC to the Internet Time Server so it will maintain the same accuracy.

Note that once the SETSYSTEM 253,2 is run it will stop re-enabling the hourly update from the backup RTC until any of the TIME[n] or DATE[n] variable is written to. Writing to any of these variables automatically re-enable the periodic update from backup RTC. (So if you are updating the PLC's RTC from Internet Time Server you will need to re-run the SETSYSTEM 253,2 statement to disable the updates again.)

So your program could disable the update from FRAM-RTC before midnight crossover and re-enable after midnight crossover.  Usually you can monitor the RTC in your program and do the necessary, or you can also setup an Alarm interrupt to handle it automatically. I have attached a sample program demonstrating how to use the alarm interrupt to work around this issue.

Thank you for the updates. Our tech support team has also emailed you some suggestions on the possible causes of what you observed but we are glad that in the end you found out that it was a simple ground wiring issue.

Yes your understanding of the PMON capability is perfectly right!

The PULSEFREQUENCY, PULSEPERIOD etc are handled in the background. Some input capture timers at work capturing the exact time when the pulse edge occur and when TBASIC execute the PULSEPERIOD command the actual period is computed.

Note that PULSEPERIOD(n)  returns 32-bit number so you probably want to use a 32-bit variable to store the data  since period is measured in 1us to 0.1us, so for low frequency pulse the period is a very large number.

You can use A to Z or DM32[1] to DM32[2000] to store the 32-bit PULSEPERIOD data.

Thank you for your report. So far we have not encountered similar issue nor hear from other customers about the random scrolling behavior.

1) What is your operating system?

2) Does this happen every time you run the program? How long on average when this behavior starts to appear? Is the screen scrolling horizontally or vertically?

3) Are you using laptop? Could the touch pad on the laptop be contributing to this behavior?

4) If you quit TL7 and then run the program again, does it become stable?

5) If you restart the PC operating system does it become stable?

Given that the Nano-10 is on 4G network which is likely to be less stable than the internet connection at the ISP, it will probably be better for the Nano-10 to update the status on the F2424. If you are just monitoring digital inputs you also can report only when there is a change of logic state and when nothing change the Nano-10 need not report the state to the Fx2424 (or at least report much less frequently).

Nano-10 can send a NETCMD$ and check for response from the Fx2424. If there is no response it can try again and if still no response, there is probably a loss connection and the Nano-10 can do the necessary such as disconnect and make a new connection. In some cases it may need to restart the 4G modem in order to resolve the connection problem. These are possible if Nano-10 can control the power to the 4G modem.

Thank you for your feedback. Your suggestions will be sent to the software development team for consideration.

Note that you can export the custom functions to a text file and you can the edit the text file to retain only custom function of interest before you send them to paper printout. That may be a short term fix for the moment.

The gateway function of the Nano-10 supports only the Modbus RTU mode as well as the Hostlink command mode but not the Modbus ASCII mode. Modbus ASCII is much less often used than Modbus RTU mode and therefore there has been no plan to add this mode to the gateway function.