Problem transferring to PAC

I have an intractible problem that has me tearing my hair out (which I can hardly afford to do), and swearing at the PICED software a lot...

In a nutshell, I just plain cannot transfer the program to the unit. - whenever I try, I get an error: Error 14023 - Could not connect to serial port. - Unable to open com port (win error code: 5)

Any ideas?

I AM perfectly able to connect to CBUS, show network states, show units, etc. so the serial (USB) connection would appear to be OK.

I did have one "odd" occurrence earlier, - but I had this same error before it happened.. - I installed Toolkit & PICED the other day, and installed the USB driver etc. - all with no problems evident, and all able to connect as above, and program units etc. (still wasn't able to transfer though). then today when I rebooted the machine, - the add new hardware wizard ran again for some reason, re-detected the PAC, and made me install the driver again. - as a result of which the dirver installed yet another COM port, and the COM port address had to be chaned in the project. Once changed connecting to CBUS worked OK again (still can't transfer though). - this has also left a "phantom" serial port on the first COM port the driver setup - this is now missing from device manager, but has left a load of stuff in the registry (which I can't delete) - not terribly impressed / happy about that....

I am running this on W2K3 server,
latest version (as of today) of CGATE, Toolkit, & PICED.
I have the standard COM1 & COM2 ports from the motherboard,
I have an 8 port PCI serial card fitted which gived COM3-COM10 inclusive
The first time I installed the PAC driver it setup COM11 (which worked as described above).
Today after rebooting it re-installed the driver and setup COM12.

COM11 is now "missing" from device manager, but I#ve updated the PICED & Toolkikt software to COM12 and that seems to be working OK for everything except being able to transfer..

Any ideas anyone?

Many thanks

Paul G.

 

Hey mate,

I cant directly answer your question, but windows server 2k3 runs things a little differently to "home" versions of windows. It might be prudent to try running everything on a standard XP/Me/98 computer.

Also, how come you arent using the COM1 or COM2 ports on the motherboard?

Darpa

 

When you plug in a PAC, do you see "C-Bus Pascal Automation Controller" appear in the device manager under "ports" ?

 

Problem transferring to a PAC

Hi chaps. - thanks for the suggestions...

1st answer: - it's a PAC, - I'm using the USB port, thus I'm using the USB - virtual COM port driver, - thus it installs a new COM port in windows at the next available COM port number...

2nd answer: - yes, I do indeed see "C-Bus Pascal Automation Controller" in device manager, and as I mentioned, is is (now) listed as beinf COM12. - I *CAN* use that quite happily in both Toolkit and PICED to connecto to CBUS, scan the network, and so on... I can open the network in PICED, show units, etc... - the only things that seem not to work are the items on the transfer menu - either "connect to unit" or "transfer..." result in the error message I detailed... - I'm assuming that since connecting to CBUS works OK, then that suggests the COM connection is fine...

I will try connecting from another PC when I get a chance (I'm not at home till the weekend, and I'm doing all this remotely via VPN), however, I'd rather get it working from this server as it is my main building automation controller.

Cheers.

Paul G.

 

Once you have used the PAC as a PC Interface to communicate with C-Bus, it will be locked in that mode until you remove the USB cable or C-Bus cable. If you have used the PAC as a PCI, then remove the cables, re-connect the cables and then try to connect to the PAC for a transfer.

 

AHA! - that sounds plausible... - thanks for that, - I will try at the weekend when I get home. - I had actually been wondering how the whole PAC/PCI thing worked... - I had come across info before about the mutually exclusive nature of the two functions, so I knew that (to paraphrase) it stopped being a PAC when it was used as a PCI, but I hadn't seen any info about how that mechanism actually worked... - with the removal of the USB cable, - do you know how this is detected at the PAC? - I'm wondering if rebooting the attached server would have the effect of simulating the USB cable being disconnected? - although a reboot wouldn't actually cut power to the PC's USB ports, so I suspect not... Hmm...

Which does lead to a whole raft of other questions... - like how do people in general manage the use of their PAC with regard to utilising the two functions? - this is a bit of an issue for me, since 90% of the time I'm not on site to physically plug cables in/out, - I access remotely via VPN into the BMS server... I need to be able to use BOTH toolkit for CBUS management stuff, and PICED for managing PAC code... - clearly it now seems I can't do this without a means of being there to do the cable thing... - I do also have a PCI connected on the same BMS server, on another COM port, which is connected to CBUS, so it would seem sensible to dedicate this to toolkit.. Now, the COM port can be specified independently in both toolkit & PICED can't it... so do you think that this should work seamlessly?... i.e. one instance of CGATE, one instance of toolkit using COM5, and one instance of PICED using COM12...

Cheers.

Paul G.

 

Hey Paul,

I cant give you any advice specifically about the C-Bus components, but if you need something that you can remotely (Ie; via a VPN) connect and disconnect the USB cable on a physical level, I could manufacture a USB cable for you with relay-switching in the middle of it, that could be controlled by software control, (thus remotely). Although it sounds to me like your plan of using the PAC and the PCI in conjunction with each other could do the job for you perfectly.

So good luck either way mate

Darpa

 

Actually, I've just tried setting up the scenario I described in my last post - i.e. toolkit set to COM5, - and it has worked! - just transferred the program (and newer firmware) to the PAC with no problems! - and WITHOUT disconnecting any of the cables... I think I know what the problem was... I think it was CGATE holding the COM port locked... I had toolkit set to NOT close down CGATE on exit, so even though I new I wouldn't be able to have both toolkit & PICED both set to use COM12, and both running at the same time (obviously only 1 would be able to open COM12 at a time).... when I shutdown toolkit in order to run PICED, CGATE was still running, and presumably still keeping COM12 open. I got no COM port conflict errors at all from PICED using COM12 to access CBUS, - again presumably because it was doing so via CGATE, which already had COM12 open, so no problems...

However, when in PICED, I closed the netwok, & attempted to transfer, apparently this was attempting to open the COM port again - hence the conflict, since it was still in use by CGATE... - this suggests that PICED does not use CGATE to access the PAC for program transfer....

I have now reset toolkit to use COM5 for my project, and shutdown CGATE. Thus when tookit starts, it starts up CGATE, and opens COM5... then I opened PICED (still set to COM12) - I even opened the network via the PAC (so PAC operating as a PCI), - closed it again, (no unplug of cables or anything).. and then tried the transfer... voila!

Cheers for all the suggestions...

Paul G.