Internet PLC Forum

The EEPROM on Wx100 has erase/write cycle life of 1 million cycles. Erasing and writing of EEPROM cells does take a bit of time and may affect the PLC scan time. When you save a string to the EEPROM you are saving multiple bytes of data (up to 40 bytes per string) so the time delay multiplies by the number of bytes.

If you are developing an OEM equipment that you intend to manufacture in quantity (> 100 per year) then it is possible to add other useful components that can enhance your application need such as FRAM (works like EEPROM but with no life limit and a lot faster - writing to FRAM takes very little time since there is no "erase" cycles to deal with).

Wx100 is an excellent brain board platform (similar to our SmartTILE-Fx brain board system) that allows OEM customers to design and build their own custom carrier board (we call these "terminal boards" in Wx100) which can include customized components such as FRAM and battery-backed RTC (for applications that have no internet connection but still need to keep a real time clock running).  Please contact support@triplc.com to discuss your application if you wish to pursue an OEM custom terminal board design.

We are currently also adding new HTTP client capability which allows Wx100 to very easily connect to a HTTP or HTTPS web server to upload data via HTTP POST protocol, or download data from a web server via HTTP GET protocol. You can also log data to local data files in your PLC file system and then periodically upload the selected files to web server via HTTP mutlipart POST protocol before deleting it. This is in addition to the support of MQTT protocol already available on your Wx100 and thus further enhancing its IIoT capability.

You may like to consider using these new capability to log your data to a web server for permanent storage when it becomes available (should be pretty soon). Please register your interest by emailing to: support@triplc.com and we will contact you to provide free upgrade instructions when the new software and firmware are released.

If the MBTCP time-out is set to zero then the firmware will automatically adjust the MBTCP server time-out to 20 seconds.

Note that this time-out is for the PLC acting as slave (Server) to an external Modbus TCP master (client). 

Did you try to run "PRINT #4 "<TCPCONNECT xxxx>"? Note that TCPCONNECT is for the PLC to act as a client to access an external TCP server. It is not to be used to configure the PLC as a Modbus TCP server.

I checked the Moxa 5230 - it appears to be a MODBUS TCP-to-MODBUS RTU gateway converter? If you want to access the serial port on the Fx1616-BA PLC from an external Mobdus TCP master then MOXA 5230 can be used but you must configure the serial port on the MOXA to be compatible to that on the PLC. I don't understand why do you want to do that since you can already directly access the PLC via its Ethernet port...

There isn't a Special Clock Pulse bit with a period of 2 seconds.

But there is a 1 second period clock named "Clk:1.0s.

You can use a COUNTER to generate a 2 second clock from Clk:1.0s

The trick is to make the COUTNER count up with the use of special function coil, [UpCntr].

A COUNTER with a set value of 1 will count 0,1,0,1... as an up-counter. The contact for the COUTNER will be active on the "0" count time period.

I have attached a screen shot of of the ladder logic to get this to happen.

Good luck,
   
Gary Dickinson

Gary I had had a similar issue and when I did some detailed testing I discovered that there was a 24VDC relay that was connected to a PLC output and the manufacture of the equipment forgot to install a diode across the coil. Be-leave it or not that spike created cause the PLC to call my interrupt that I used to reset the HSC value. 
I found out with some help from tech support that within the interrupt I could disable the interrupt then I could do a quick Refresh and read the input that was tied to the interrupt which now is at level logic then reset my HSC value then re-enable the interrupt . All this added less than 1ms which actually prevented the spike from resetting the HSC and was still more than fast enough to reset the HSC value instantly. 

Gary
I think you have the right idea but you are over doing it.
Leave the Interrupt as a Rising Edge trigger then in the first line of the function disable the interrupt then do a REFRESH of the IO then do a TESTBIT of the input you want then you can set any relay you want or reset any counters etc.
Then before you exit turn the interrupt back on.
Then in your ladder logic you can reset the relay you set in the function any way you want