ABACOM - ELECTRONIC SOFTWARE

Good evening all hope you can help,

I have just come across a massive problem that has disabled pretty much every program i have made. I tested multiple parts and found the issue is with the com communications (Send string/receive string/value). I have used this for over 13 years with no issues, but during some recent working my program started crashing immediately on run and going back to old programs the same issue stands.

After much troubleshooting I found the only way to stop the hang is to set every com value to com1, any other value causes massive hangs and with my large projects just crashes entirely. I have confirmed this on multiple old and new programs and have attached a sample for you to see.

The sample is a simple send receive chain i would normally use, the value for coms starting at the default of 0. The stopwatch shows clearly while you are watching the program hangs for multiple seconds at a time with any com value other than 1. When changing to 1, the program runs perfectly with no hangs. Even changing a few back to another number (com2) caused the hang again.

This new issue will completely stop all my programs from working if i have to recompile for any reason (I have programs running 30+ coms commands), would appreciate any help to resolve the issue.

Hi Peter,
In which country setting is your ProfiLab running? Unfortunately, I cannot load your example program into ProfiLab to view your problem.

THX

Peter, I got your email and just answered to it. Make sure your addressing ports that are available
in your system and suitable for your project. Otherwise your running into exceptional condition,
where PL will try reconnecting the non-available ports, causing what you call "hangs".

In case your app is meant to run without having COM device(s) connected, you´ll have to disable the clock
permantly triggering requests to it.

(@THX: Peters above project opens without any issue in current PL version.)

Thank you Admin, Ive never had this issue before in over 10 years thus the confusion and typically i run tests with the program with no coms connected to put calibration data in before compiling and sending to customer (Coms are typically the same as customers pc, often 3 and 4)
Will test on customers pc over the next few days and report back.

To update the above solution is correct,
putting the program on the clients pc resulted in the same issue on a com number "not assigned" before (com 0 as the obvious one), once i assigned a com number that windows was aware of (comm3/4) the issue completely dissapeared.
To sum up, a fresh install pc will have issues opening a program made to talk to com numbers that have not been registered yet.