Socket Error #10061

Check in IQANdesign and in IQANsimulate that they have the communication option for simulator is set to the same port. Default is 8325, maybe you have changed this by accident? 

Hi Gustav,

Yes I had already checked those settings, and they were both at 8325. I even tried changing these values but the problem exists. So they are now still at 8325.

Note, this problem occurs on another PC that I also run on, so not just happening on one PC.

I've dug a bit deeper, and after much deleting, i can narrow this problem down to the new updated state picker ( changed for 6.05 ) in a MD4-10 display screen linked to a State Parameter channel within the MC43.

If I have only a few state pickers then the project will run fine through Simulate. If I have 20 state pickers, I get a Socket Error when I run through simulate.

Note, the state parameters need to be in the MC43, and selected through state pickers all within the same display page, for the socket error to show up.

Thanks,

Thank you Tony, very interesting to hear that it seems related to number of state picker in a multi-master system. Investigating.

After giving it some thought, I think the extremely delayed startup of IQANsimulate is a logical explanation for the message about socket error in IQANdesign. 

So then the question remains why it takes such a long time to start the application in IQANsimulate.. If you only start the simulation from IQANsimulate, do you see the same problem? 

Tried reproducing with a small application, but without success. This number of state pickers for parameters on another module was not enough to reproduce. 

The quickest way to investigate would be to look at the application. 

Perhaps you can consider sharing a copy of your application via your local Parker sales contact? 

Hi Gustav,

I have uploaded a simple test project that replicates the error.

Sent to you directly through the IQAN share file link.

Thanks, Tony

Thank you Tony. When I try the project file, simulation starts every time. For me it takes 3-4 seconds for the simulation to start when launching from IQANdesign, about the same time when launching from IQANsimulate. 

How does it behave on your PC if you start the simulation from IQANsimulate? 

For me, when I open this test program in IQANsimulate, it takes approx 10 seconds to run. When I open and run through IQANdesign it's the same ( although I see the socket error ).

This is the same for my main PC as well as my laptop. Both are powerful machines.

When I open a much larger project with the same configuration of state pickers, it can take around 60 seconds to run on Simulate.

While it is loading the program and trying to run in Simulate, the IQANsimulate program stalls and is frozen. Once it eventually starts up through Simulate, everything works fine except the communication between Simulate and Design ( because of the Socket error )

Thanks

Also please note, this problem only occurred since upgrading to IQANdesign 6.05.

The same project when running on Version 6.04 works perfectly fine. No delays when opening with IQANsimulate and no socket error.

It sounds as if there might be something slowing down IQANsimulate when starting on your PC. One idea to try to see if it makes a difference could be to add IQANsimulate as an exception for your software firewall and antivirus. 

The one difference with 6.05 that I can think of is that more of the display page initialization is done at startup. This change enables faster page navigation, but in at least one case the side effect of longer startup has been so significant it is a problem, see discussion here. 

Hi Gustav,

Even with antivirus and firewalls turned off, it makes no difference. ( antivirus is just the standard inbuilt windows defender ).

Adding an exception makes no difference.

Monitoring IQANsimulate process while its trying to run the project, and it comes up as "not responding" and 0.1% of CPU. Nothing else is loading the system. CPU and Memory usage are both low while this happens.

Remember this is happening on more than one PC.

Thanks

Strange. Even with some more state pickers than you had, I'm still unable to reproduce. Attached is the application with what I have tried so far: GW test state picker 6.05.idsx

One longshot to try is to check if there is some other program using the same port. 

If you open a command prompt as admin, you can check this using

netstat /b

That this would be the issue seems less likely, as you wrote you already tried a different port setting, and also that it would probably mess with earlier versions too. 

Hi Gustav,

Couldn't find anything using the same port.

Correct, changing the port settings makes no difference.

Problem occurs on my main PC as well as my laptop.

Running your sample program also produces the socket error.

Your sample program also lags badly when switching between screens on the simulator.

Shifting all of your state pickers to the MD4 application fixes the issue with the socket error, and also fixes the lag issue when moving between display screens with state pickers in them.

The solution on my application is going to be moving all of my state pickers to the MD4, even though I wanted to keep as much spare memory as possible in the screen for data recording that I need to do.

Thanks for your assistance in looking into this. Not sure what is causing it, but I can't spend any more time trying to solve it.

Cheers

Thank you Tony. The symptom sounds as if it is the signals simulating multi-master diagnostic traffic that are somehow delayed. These signals use different ports than the basic port setting you set in IQANsimulate, instead these are set at each startup to avoid conflict. (the other ports you probably saw IQANsimulate using when running netstat)

I'll mark this one as "not reproducible", at least for now. 

The post is still visible here if anyone else bumps into the same issue.

I run into this 10061 issue on multi-master programs.

Latest 6.08 design and latest 6.08 simulate.

They both list the same port.

I find multi-master lags a lot in general. In particular the measure groups on real hardware is annoyingly slow.