This error is occurring with PAC Control 9.3b in Windows 7 Pro (64x) and Windows 8 Home (64x). When adding a control engine name “mycontroller” (for example) it is showed as “\mycontroller\mycontroller” and it returns a -8626 error (Invalid control engine name. Control engine not configured (name not in Windows Registry).
UPDATE:
The -8626 error: Control Engine definition work-around and KB
Also see this KB article KB83358 for some work-arounds. The one that’s worked consistently for me is #3: right-click on your shortcut to run PAC Control as Admin, then re-add your control engine definition. That seems to “stick.”
I’m having the same problem, on a laptop with Windows 8 64 bit. When I create a control engine, and assign an IP address, no path slashes are shown in the name. If I modify it, the IP address has not been saved. When I select the control engine and hit OK, it will change the name. For example, I set up a controller called ‘Controller’, it will end up as ‘\Controller\Controller’, and not work.
I’ve done a bit more research, and this might help your software team.
On my Windows 7 machine, the control engine information for one called ‘TestController’ ends up in a registry key at:
HKEY_LOCAL_MACHINE\Software\Opto22\Control Engines\TestController
On my Windows 8 machine, it’s in this one:
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Opto22\Control Engines\TestController
I went so far as to create a key at the path that the Windows 7 machine uses, to no avail. It’s clear that the software is making the key one way, and retrieving it another, and Windows isn’t playing fair along the way, and not giving back on Windows 8 when it’s asked for.
Thanks for the info, Todd! I’ve passed this along to the relevant developer(s).
-OptoMary
Hi Mary,
I’m having the same problems here as Germinal with Windows 8. No progress towards a solution, but I can attest that this problem did not always exist. When I first migrated the files from a Windows 7 machine to the current Windows 8 machine, I did not experience this error. If I save the .idb file and open on a Win7 machine, I do not have a problem.
I’m wondering if the control engine issue in Windoze 8 has been addressed at all. Because they really aren’t selling anything else, we’re ending up with a number of W8 laptops, and the problem is becoming huge for me in a support way- I’ve got a guy in the field now who can’t load a program on a unit. The odd thing is that it worked for him for a week, then suddenly it doesn’t.
I managed to work around it on my own laptop, but only by using a virtual Windows 7 machine running within the laptop, which isn’t really a so much a work-around as it is a brute-force solution. This won’t work long-term.
Any idea on a time-frame for a fix?
Hi Todd,
We’ve been trying to reproduce these reported issues here, but so far no luck. We’ve tried windows 8-32 bit, and 64-bit, and Windows 7 64-bit. We could use as much detail as possible regarding the version of Windows 8 being run when this occurs.
Also, we’re wondering if the problem might go away if you change the program to run in Windows XP service pack 8 compatibility mode (right-click on start icon for program; Choose Compatibility tab; select “Run this program in compatibility mode for: Windows XP (Service Pack 3)”). Don’t know if this will fix the issues since we’ve not been able to get them to happen, but it’s something to try.
The rest of you reporting Windows 8 issues, please share any/all details you can offer so we can get to the bottom of this!
Thanks,
-OptoMary
Ok, here’s some progress-
I thought I’d run the compatibility modes before, but figured before I posted to that effect I’d give it another try to be sure. I started out by trying Windows 7 compatibility mode. There was change- the control engines would still not create or save correctly. When I closed the program, the system popped up a Program Compatibility Troubleshooter, which suggested what you mentioned- Windows XP (Service Pack 3). I applied it and tested that, and lo and behold, it now works as it’s supposed to- I can create and use control engines in PAC Control. I then tested this also in PAC Terminal- in XP SP3 mode, it’s working.
Now comes the really interesting part - in the interests of checking everything, I went back and unchecked the compatiblity mode, so it’s back to native Windows 8. Now it works fine, even without compatibility mode. I did find that engines created while the program was in compatibility mode can’t be deleted while out of the mode, and vice-versa. It would appear that the two modes overlap somewhere, but can’t modify one another.
After deleting every control engine created with both programs, and clearing compatibility mode, both programs still operate well, and allow creation of and use of control engines. I’m going to theorize here that the program is unable to create a key group correctly in Windows 8, and that by using compatibility mode, the group was initialized, and is retained even if all the engines are deleted.
I was going to offer to allow your engineers to access my machine remotely, but now it’s working, so it may not be of any use. If it would still be, please let me know and we’ll work out a remote access.
Thanks, Todd! Our engineers were just finding a very similar work-around, and I’ll share a link to the KB ASAP. Bottom line is we’ll tell folks that IF they run into this problem (and we haven’t narrowed down the cause but we did finally manage to see it once), you’d do something like what you did – run PAC Term (or whatever you use to configure the control engine) is Windows XP SP 3 mode to create them “good” control engine definitions.
Important note: this is only a temporary work-around until the root cause of this problem is fully understood and thus fixed properly.
BTW, one suspected cause/trigger relates to uninstalling PAC Project and re-installing a newer one. Any chance you’ve done an un-install recently?
THANKS AGAIN!
I do keep up with versions, so it’s likely it’s been updated at some point. Because I have several different folks using the products, I keep everyone up to the latest so we don’t run into version issues. Couldn’t say for sure, though… I do know that my service technician did not update or uninstall/reinstall between his working and not working. Using the compatibility mode worked to fix his issues.
I have several customers that have had similar issues. Yes they had removed / upgraded software. It also seems that the PAC applications (terminal, manager, control, dispconfig) may handle reading & writing the controller settings in the registry differently.
Yesterday I verified that PAC Terminal and DispC do not read/write to the same registry area. A controller you can see in Terminal is not there for DispC to use.
This morning one of my customers lost their controller. I tried to re-enter it from PACControl. I typed the name and it added the slashes as described earlier. I removed the controller and rebooted. Still added the slashes. Then I ran Opto Term as admin and added the controller. That worked. Very strange. This issue has been around in at least the last two versions of PACProf. It really needs addressed. It is not good to log into a system and find that you cant get to the control engine. I have already done the tech support thing last spring and did not get it resolved. They could not re-create the problem.
All,
We are working hard to make the next release of PAC Project Win 8 proof.
This controller/PAC Term issue is well known to the software team, so a fix is in the works.
Thanks for the hints for working around it in the mean time (I personally have had to use some of them!)
Ben.
Just wanted to chime in with this.
I am running win8.1 and had the identical problem as described, i.e //controller/controller name and the IP address not being saved.
My solution was to simple restart pac control with admin rights and all was good again. It seems that something in the windows UAC may be getting in the way.
kevin
It all starts when I open a project in Pac Control Pro and try to enter debug mode.
I get the following window:
I check the control engines and find the IP is gone.
I put the IP back in and get this weird “relative path” naming that still doesn’t work.
When this has happened I have tried adding a new engine and it gives the new engine a weird “relative path” name. For example “\ est_engine est_engine”.
This is on a Dell Venue Pro running Windows 8.1 32 bit.
All of the Strategy files reside on my OneDrive for easy sharing/syncing between my laptop and tablet. My laptop works fine this way and has not had any issues at all. It is running Windows 7 64 bit. Is this a Windows 8.1 issue? My tablet does work fine for awhile (days/weeks) before this happens. The only way I have found to fix this is to re-format the tablet and start over.
Any help is appreciated.
~Nick
Hi nickvnlr,
Hope you don’t mind, but I moved your thread to the topic that covers this… The search is tough enough to use without there being more than one post of the same topic in different places…
Opto has got a fix for this issue in the works, so use the work around for now, and be sure and subscribe to OptoNews so you can be notified via email as soon as the new PAC Project is out.
Cheers,
Ben
Also see this KB article KB83358 for some work-arounds. The one that’s worked consistently for me is #3: right-click on your shortcut to run PAC Control as Admin, then re-add your control engine definition. That seems to “stick.”
Thank you. It’s hard to search for something when I don’t know what to search for… 
I am glad to see it wasn’t just me.
