When serial/TCP converter has powered down, connection is not restored automatic

[Toot]

Which is the correct setting to automatically reconnect to the TCP port after the was a problem with the hardware serial converter? I noticed that my devices will not reconnect automatically. The device is not ready to send data. Not until i restart the datalogger software. I assume the hardware device recieves an initial "ready to send" signal.

[Adamastor77]

I am experiencing the same problem and it is not yet solved. You can have a look at the previous topic:  (Advanced TCP/IP data logger (Professional)


http://forum.aggsoft.com/index.php/topic,347.0.html


The last piece of advice given to me by Mr. Grasin sounds good:  activate the KeepAlive function and see if it changes anything. I haven't yet had time to test it. I will try that next week.

If you test it in system mode, just make sure the two entry names described in the TCP/IP logger manual on page 17 exist (KeepAliveTime and KeepAliveInterval). If not, create them. Be very careful when you make changes to the windows registry though. It is better to create a restore point in windows (C:\Windows\system32\restore\rstrui.exe) before you make any change in the Windows registry.

I will let you know in this forum whether my tests work or not. I would be interested in knowing about yours also.


Regards
   Luis

[Toot]

Luis,

thanks for your reply, i am going to try this and wil let you know, i am currently trying to find out why the datalogger software stops by itself. The icon stays down at the bottom but when you point at it it disappears.

One thing you could consider is to try using the com driver for the hardware. I am thinking there is an compatibility issue, but im not done testing yet

Otto

[Adamastor77]

Otto,


I use the software to get some measurement results made by a machine-tool. This machine-tool machines parts and at the end of the machining, a measurement probe checks if part dimensions are within the tolerances or not. At the end of the probing, results are sent in ascii through one of the serial ports of the machine.
In this application, the data flow is the following:

Machine-tool (RS232 port) --> serial-tcp converter (hardware MOXA NPort 5110) ---> network ---> Advanced TCP/IP data logger (installed on virtual pc on Windows server) --> text file

Each data packet is sent about every 1h30m. The size is of each data packet is quite small (~ 1kb).

As in your case, the logging should be reliable. For us, what I have seen is that when we try to send data from the machine when serial-tcp hardware has been switched off and on, it crashes the numeric command of machine. Operator should restart the machine to launch a new part. But at the end of measurements, machine NC will crash again and no data will be saved. This is not acceptable for us as it implies a loss of time for our production and therefore a loss of money.

This is not only caused by power breakdowns (which are quite rare in Switzerland), but the operator can decide to restart machine at any time if he thinks something is going sideways with the machining.


What I haven't experienced yet is the stopping of datalogger software as you describe it.

In my case, the fact that data logger software is installed on a virtual pc could be a cause why it doesn't work. I will make some tests from a real PC through the network.

It's sad that the test you made with KeepAlive mode didn't work. I have asked a question about it to Mr. Grasin: how can we see that software actually checks the connection by sending KeepAlive signal ? We don't even know if software actually does it or not.


Regards

[Toot]

Thanks for your explanation very interesting to read some different application. My application i have wrote in VBA with access. The datalogger is listinging to three tcp/ip-serial converters.  It's three weight scales connected to it. Since i am only getting a weight string from the scale i have made a interface that compares the weight and checks if it is within tolerance. Then i have another weight scale on the far end of the building that we just use to weight scrap and my database just adds it all up. Saves alot of time. For that one i use a ACT1000. the other three are BF430's. Honestly i've had better succes with the ACT1000. It's looks very similar to the Moxa. probably same internals. also same Com software with the swiss army knife. The original com port driver probably acts different then the TCP/IP software from Agg. I do like very much the datalogger part from Agg. It seems very stable and has lot's of features. Needless to say, my tcp ports always need to stay open. And after power failure or other glitch it needs to reconnect. That is the part i am worried about. Right now i have handshake issues between the BF430's and the TCP/IP software.

I have never tried to send signals in the other direction like you want to do. The hardware says it's possible. In my case i won;t loose production but valuable recorded data. i will get random measurements about every 1-2 minute. since the ACT1000 is very low cost i am also thinking about getting three more of those.

Good luck with you application

[Toot]

Luis,

I just wanted to let you know that i have succesfully tested 4 ACT1000's connected to TCP/IP data logger. Only glitch is that when power fails at the converters the connection needs to be reset in the TCP/IP software. Just hit pause and play button is enough. This i will have to find a solution for still. But the connection otherwise is rock solid. The ports are always open and ready to recieve data.

my data goes to a access database. now i will need to find out a way to refresh the form upon recieving new data. this has proven some difficulties sofar.

Anyway, i promissed you an update, there it is.
Good luck,
Otto

[Arthur Grasin]

Otto,

If the program uses KeepAlive, then the connection will be reset automatically. But sometimes, KeepAlive doesn't work

[Toot]

Athur,
is there a way to to remotely pause/start the TCP/IP datalogger software? Via DDE or ODBC, activeX or any other way? I would like to create a button on my msaccess application to reset this. That would solve the keep alive issue. I already tested the keep alive with my ACT converters. It's not working.

Thanks,
Otto