DmDesigner.exe Application Error

[ryanastiefes]

I always get an error from DmDesigner every time I shut down my laptop after I've used the DmDesigner. Attached is the error. How should I go about fixing this? Do I reinstall the software or is this a permission problem?

[franji1]

Yes, you need to shut down Designer before you shut down the PC.

Designer utilizes a 2nd executable, the Comm Server.  As you shut down your PC, Windows decides what EXEs it shuts down when.  Hence, if it decides to shut down the CommServer (CSMainDm.exe) first before Designer (DmDesigner.exe), Designer will fault.

[ryanastiefes]

Got it, thank you

[franji1]

Strange things also happens when a PC/laptop goes to sleep or hibernates with Designer running.  The handles shared between Designer and the Comm Server are not maintained by Windows (e.g. a USB port handle, for example), so when you come out of hibernation, strange things occur.

If you truly need Designer up and running (e.g. debugging, trending, logging, etc.), best to turn off/disable any/all sleep modes or power saving modes (don't shut down that USB port Windows, it's in-use!!!).

[Bolt]

While this is "how it is", it's not ideal.  Some other programs, such as Click Programming Software, I can close my laptop, unplug the ethernet cable, and walk away. I can come back in a day or two, plug in the ethernet cable, open the laptop, and the very quickly the data in the Data View that was still open starts to show current data again.

Meanwhile, if I'm connected on my desktop to two BRX's at a customer site via a StrideLinx VPN and the connection flutters, I spend the next several minutes in both open DmD instances trying to click PLC->Disconnect..., and go through the next several popups.  First Yes, then No, then No again, and one more No for good measure.  If I don't get one instance completely "disconnected", the other instance will likely freeze up and I'll never get it "disconnected", and end up having to kill DmD in Task Manager and start over.  Every once in a while I will even have to reboot my PC to really get back to work.  Windows will then insist on my latest updates, and you all know the story...

I know it's two completely different use cases, one is a glorified smart relay while the other is crunching data in microseconds paired with a powerful suite of real time trending capabilities, but the user experience can be frustrating to say the least.

[franji1]

Agreed.  If we had control of all VPN and O/S code we could probably figure it out.  It is much more difficult when it is a "black box.

[BobO]

While this is "how it is", it's not ideal.  Some other programs, such as Click Programming Software, I can close my laptop, unplug the ethernet cable, and walk away. I can come back in a day or two, plug in the ethernet cable, open the laptop, and the very quickly the data in the Data View that was still open starts to show current data again.

Meanwhile, if I'm connected on my desktop to two BRX's at a customer site via a StrideLinx VPN and the connection flutters, I spend the next several minutes in both open DmD instances trying to click PLC->Disconnect..., and go through the next several popups.  First Yes, then No, then No again, and one more No for good measure.  If I don't get one instance completely "disconnected", the other instance will likely freeze up and I'll never get it "disconnected", and end up having to kill DmD in Task Manager and start over.  Every once in a while I will even have to reboot my PC to really get back to work.  Windows will then insist on my latest updates, and you all know the story...

I know it's two completely different use cases, one is a glorified smart relay while the other is crunching data in microseconds paired with a powerful suite of real time trending capabilities, but the user experience can be frustrating to say the least.

None of that really has anything to do with the PLC's capability, it's tied to an architecture built to do a lot of things that really don't even matter any more. When we first wrote DSP back in the 90s, we designed the comm server to provide comm services to a full suite of applications...programming, HMI, data servers, etc. Since multi-drop serial was a common thing, you needed to be able to share a single serial port across multiple links and multiple apps. Wasn't an easy task. The Comm Server was the answer. Serial faded, Ethernet/USB took over, and we never really pursued the multi-app suite, so the need for a standalone comm server was diminished. After getting something working, particularly something as critical and complicated as comm is to a PLC, we've been reluctant to touch it. At this point it probably makes sense to eliminate the standalone app and move all comm services in-process...but...it's a lot of work that provides no new capability to users, so it tends to get kicked down the road in favor of things you can use.