Do-More Multiple instances

[JeffS]

I noticed that if you have more than one instance of Do-more open you can only actively connect/write to a single PLC without crashing all instances that are actively writing/connecting.

I often connect remotely to sites that have many PLCS that require updates.  Right now I have to do each one separately making the process take awhile, I would be awesome to start one, then start another while that one is writing.

Anyway this could be fixed so that two instances can connect to two different PLCs at the same time and write at the same time without breaking the program?

[BobO]

I noticed that if you have more than one instance of Do-more open you can only actively connect/write to a single PLC without crashing all instances that are actively writing/connecting.

I often connect remotely to sites that have many PLCS that require updates.  Right now I have to do each one separately making the process take awhile, I would be awesome to start one, then start another while that one is writing.

Anyway this could be fixed so that two instances can connect to two different PLCs at the same time and write at the same time without breaking the program?

It's not supposed to be that way and we're actively working on that exact issue. It appears to be bad re-entrance brought on by some update monitoring that got added along the way.

[Bolt]

It's not supposed to be that way and we're actively working on that exact issue. It appears to be bad re-entrance brought on by some update monitoring that got added along the way.

Can you also please address the overly restrictive comms, for example, if I'm connected to a PLC via VPN to a customer with marginal internet connection, I can't even click a link in my web browser if there happens to be a transport protocol error on the DmD connection.

[BobO]

It's not supposed to be that way and we're actively working on that exact issue. It appears to be bad re-entrance brought on by some update monitoring that got added along the way.

Can you also please address the overly restrictive comms, for example, if I'm connected to a PLC via VPN to a customer with marginal internet connection, I can't even click a link in my web browser if there happens to be a transport protocol error on the DmD connection.

Not sure about that. I routinely work with broken comms while debugging the PLC and I've never seen anything like that.

The only time I see stuff like that is on startup, and I've never been able to figure out why it behaves that way. I'm definitely not a fan.

[Bolt]

Not sure about that. I routinely work with broken comms while debugging the PLC and I've never seen anything like that.

The only time I see stuff like that is on startup, and I've never been able to figure out why it behaves that way. I'm definitely not a fan.

I've brought it up a few times over the years:
https://forum.hosteng.com/index.php?topic=2173.msg18375#msg18375

And you've kinda answered it, at least to my understanding of the situation, but they may not be entirely related:
https://forum.hosteng.com/index.php?topic=2744.msg22169#msg22169

[JeffS]

Yeah, do-more locking the PC up so you can't interact with other applications when it is experiencing comm failures or you are writing/reading the PLC is a bit of a pain. 

Just last night I was connected to a remote do-more with a poor connection and wanted to fling my computer out the window as mouse clicks kept getting locked up because Do-more was having comm failures.  Ended up disconnecting from the PLC so I could do the other things I needed to remotely without the aggravation.

[franji1]

Here's a recent scenario of unreliable comms via "secure VPN"

Appliance is on PLC (remote) end.  Client side VPN software runs as an add-on in Edge/Chrome/whatever browser - so you must run the browser when using the remote connection.

Client side ~ VPN Host ~ Customer side
PLC=Browser ~ Secure VPN ~ Appliance=PLC

The issue was with the Secure VPN configuration being misconfigured.

Regardless, lots of layers.  Lots of configuration parameters.  Very hard to diagnose.  To say it took days is an understatement (dealing with 4 different technical contact points):
1. Host Engineering
2. ADC Customer (their product uses ADC BRX PLC)
3. VPN company
4. ADC Customer's product Customer

In this situation getting support from the VPN company is what eventually enabled us to fix the customers' issue.  They were very accommodating - not every vendor is that helpful.  The ADC Customer was the customer of the VPN, so that helped.  If it had been the Customer's customer's IT department who was the VPN customer, it would have been more difficult.

[JeffS]

If there is a possibility that our VPN setup is causing issue, I am more than happy to go over it and make any changes that need to be made.  Just let me know what you need from me. 

Normally if the connection is stable (cellular modem using OpenVPN via Viscosity) we don't have as much issue with the comm failures.  The problems usually occur once the facilities start up and begin generating significant electrical noise, then the connection becomes less reliable, and we experience the majority of the modality lockups with do-more.

[Bolt]

If there is a possibility that our VPN setup is causing issue, I am more than happy to go over it and make any changes that need to be made.  Just let me know what you need from me. 

Normally if the connection is stable (cellular modem using OPVN via Viscosity) we don't have as much issue with the comm failures.  The problems usually occur once the facilities start up and begin generating significant electrical noise, then the connection becomes less reliable, and we experience the majority of the modality lockups with do-more.

This is via OpenVPN? I access 1 site through OpenVPN, the rest of mine through StrideLinx. OpenVPN's BRX to DmD performance is quite crappy compared to the StrideLinx's, even though most of the StrideLinx sites have a significantly poorer quality of internet connection. It is anecdotal though, as it's only one site on OpenVPN, and I haven't dug into why that is.

[franji1]

If there is a possibility that our VPN setup is causing issue, I am more than happy to go over it and make any changes that need to be made.  Just let me know what you need from me. 

Normally if the connection is stable (cellular modem using OpenVPN via Viscosity) we don't have as much issue with the comm failures.  The problems usually occur once the facilities start up and begin generating significant electrical noise, then the connection becomes less reliable, and we experience the majority of the modality lockups with do-more.

We are definitely seeing issues with multiple connections on local networks, so definitely start with only having ONE session open if doing remote.  Until we can address the issue w/multiple local connections, I know we can't address a remote noisy one.

Noisy comm is never good.  Designer needs to handle that regardless.