PAC killing C-Bus communications with Comfort UCM

A couple of weeks ago I added a C-Bus UCM to my Comfort system and A PAC to my C-Bus network.

I've programmed Comfort to set group levels, on the lighting application, whenever a zone toggles or the security mode changes. This appears to work fine.
I've programmed the PAC with some basic schedules and logic, the logic mostly based around the groups set by Comfort. This works fine when running in PICED using the PAC as a PCI.

I'm finding that whenever I unplug the USB cable to the PAC to test it running in standalone mode, Comfort can no longer send messages to the C-Bus. The only way to get C-Bus comms back is to reset Comfort and plug the PAC USB back in.

Checking the status LEDs on the UCM suggests that the UCM is sending messages to C-Bus.

Any suggestions?

 

Is the PAC set for termination ? I have my CBUS UCM as the termination point in the chain, but I dont use the PAC for programming - I have an RS232 for that with an MSS100 strapped to it for LAN use.

It could be that the PAC stops working as a PAC when used for programming ?

 

I assume you mean physical wiring of the bus? I'm mainly wired as a daisy chain here, with the occasional spur to an out of reach switch. The UCM is at the end of the chain, the PAC is somewhere in the middle.

I've been using the PAC for programming the network since I got it. Only because the RS232 unit was tied up Kevin Hawkins xAP gateway. I'm going to try swapping over, program the network using the RS232 and just the PAC logic over USB.

My understanding of the PAC is that it doesn't start working as a PAC until the USB cable is disconnected. That's where my issue begins, all logic runs fine in PICED connected to through the PAC to C-Bus, UCM work fine. Transfer logic to PAC and unplug the USB and the UCM messages can no longer be seen on the network. UCM leds suggest it's sending and receiving messages, but I don't get any response from the PAC logic based around the UCM (or indeed, from the xAP gateway, all group addresses related to the UCM go quiet)

 

Can I ask what version of Comfort you're using? I'm on a rather old Comfort Pro 4.170.

 

I think I've got it.
Watch the log in Toolkit, after the PAC does a date and time broadcast, the UCM becomes unresponsive.
Date/Time isn't supported by Comfort until firmware 4.204, so it looks like I need to get an upgrade

 

Well done for thinking to use the application log in Toolkit. So many problems can be diagnosed by just looking at the messages on the bus.

The PAC sends a few different messages at power-up, but one of them is to look to see if there is another unit out there acting as a time master. If none is found, the PAC starts doing that job, and broadcasting date/time messages.

You're correct about the PAC not acting as a PAC until the USB cable is unplugged. When you unplug the cable, the unit does a full reset, which re-initialises everything and sets it running in PAC-mode.

It sounds like that old Comfort isn't properly discarding messages that it doesn't understand.

 

What threw me when first watching the log, is that the PAC doesn't send out date/time when connected as a PCI, only when the USB is disconnected. The UCM would lock up, I'd start toolkit and not see anything unusual as I'd missed the initial broadcast.
My bad really, compounded by not having a huge amount of free time to look into the issue properly. Luckily I had a few hours the other day and just left the log running before I started messing.

Am I missing some documentation to the PAC, the 14 page "manual" doesn't really tell you anything about it's default capabilities and behaviours and it's entry in the PICED help points you back to the installation manual...

 

This will affect me as I live in the UK. So, Comfort will become the time master rather than the PAC? That's probably ok for me as it's easier to tweak the time on Comfort than it is on the PAC.

 

In simple terms, if there's a USB cable plugged into a PAC, then it's just acting as a USB PC Interface. If there's no cable plugged in, then it's running as a PAC.

When you're connected to the PAC using PICED, and logic in PICED is running, all the PAC functions are actually being simulated by PICED, not run natively on the PAC. It's only after you download the project to the unit that the logic actually starts running on the PAC.

Make sense?

 

Yeah, that makes sense, I'd already gleaned that from other posts on the forum. I'm just saying, unless I'm missing some documentation or a section in the help files, that's the sort of thing that should be explicitly stated in the products documentation.

 

In the PICED FAQ, there is a topic "Using a PAC as a PCI". It seems to cover what you have been talking about, but maybe it needs some clarification. Is there anything you think we need to add?

 

Late update:-
I've upgraded the firmware in Comfort to 4.232, and my problems appears to be fixed.

How about rolling the Main, Logic and FAQ help files into one?

 

The main problem with this would be the size of the resulting file, but I agree it would make searching easier.

I think it would be best to keep the logic help file separate, but the FAQ could be merged into the main help file.

 

Now I've had things running correctly for a few days I think I see this problem. DLTs show the correct time (presumably set by Comfort), but timed/logic events based around sunrise/sunset are triggering an hour early. I assume the current fix is to program around this in the logic?

 

If your scheduled events relating to sunrise/sunset are an hour off, then your PAC/Touchscreen is confused about whether daylight savings is set or not.