In recent versions of ControlExpert, when running inside of a VMware Workstation VM, the entire application will hang whenever the cursor is moved within the ST editor window if any variables on-screen are not valid. This is a major problem because writing programs often involves the mass creation of new, not-yet-valid variables. I am making this post in an effort to save others time and agony trying to resolve this extremely irritating issue.

The Cause

According to my super-sophisticated diagnostic tests (i.e. profiling the application via dotTrace), the application hangs while waiting on the Win32 draw call which renders the red squiggly line underneath the invalid variable (incredible stuff). This only occurs on VMs with the following conditions:

• The VM's Hardware Compatibility Version is greater than Workstation 16.2.x
• The "Accelerate Graphics" VM option is Enabled

Since ControlExpert is a native application, the technical details of this bug are opaque to the public, but we can assume from the required conditions that the VMware Workstation implementation of Graphics Acceleration changed between Hardware Compatibility versions Workstation 16.2.x and Workstation 17.x.x in a way that doesn't jive with ControlExpert.

The Solution

Configure the VM running ControlExpert to use Hardware Compatibility version Workstation 16.2.x. This is a downgrade from the default in modern versions of VMWare Workstation, but the application will permit you to do it, so long as the VM is shut down.

To do this, perform the following:

1. Ensure VM is fully shut down (not paused)
2. Right click the tab of the VM at the top of the VM Workstation window
3. Select Manage > Change Hardware Compatibility
4. Use the wizard to select Hardware compatibility Workstation 16.2.x

Yes, I am aware that half-decent patch cables have boots.

I am also aware that you own at least 2 without them.

Heat shrink size: 45mm. You'll want a strip about 1" (~25mm) long for typical patch cables with the insert-molded strain relief.

Yes, I am aware that half-decent patch cables have boots.

I am also aware that you own at least 2 without them.

FS sells an assortment of industrial network switches, most of which are advertised as "L2+" (Layer 2+).

L2+ correctly describes the IES3100, IES3110, and TSN3220 series switches - non-routing switches with L2-only implementations of protocols which transcend the L2/L3 boundary, like PTP, IGMP snooping, and ERPS.

The IES5100 and IES3220/IES5120, on the other hand, advertise support for all versions of RIP, OSPF, and VRRP, meaning that these "L2+ switches" implement more routing protocols than consumer routers do. Further still, a quick glance at page 873 of the 3000-page IES3220/IES5120 configuration guide reveals a chapter group titled Layer 3 - IP Routing Configuration Guide.

To be clear, I'm not suggesting that these devices are equivalent to a fully-featured multilayer switch like the "L3" IES5220. You're not going to have DHCPv6, IS-IS, BGP, or a handful of other exotic L3 services. However, if routing traffic between VLANs is all you're after, the IES5220 is overkill.

I've been talking myself into deploying these in an upcoming project. I swear by running I/O directly to terminal blocks, and strongly encourage my customers and colleagues to do any manipulation at the terminal block and leave the I/O cards untouched. This would put an end to the matter entirely.

I've never come across anything like this on a customer site before, and I worry there's a reason for that. The biggest drawback I can see is the inability to extend them in the future should something change. What do you guys think of these?