Newbie PAC questions

Hi all

I've had my PAC in for a little while now, but only just recently started doing much with it due to being too busy with other stuff... I've spent the last few evenings pretty exhaustively reading the PAC, PICED, and logic PDF's, but I want to check if I've understood a few few concepts correctly...

My confusion was caused by the "logic engine" functions in PICED... - Is PICED running a software simulation of the same logic engine in the PAC? - this is my belief, since I can run, compile & test logic on a laptop in my hotel room with no PAC connected... - The start/stop/pause options on the logic engine in PICED refer to this software simulation yes?

Also, when I purchased the PAC I had no idea about the 100 transfer limit into the flash memory, - to say I was a bit shocked at this would be putting it mildly!! - that clearly demands that I really do need to do all the code testing & debugging "offline" before transfering into the PAC... - trouble is I'm not sure how I can test logic that is monitoring CBUS GA's for example... can I simulate CBUS groups being switched on/off entirely in PICED as well, - even when I have no connection to CBUS (in my aforementioned hotel room)?

Lastly, does the "ONCE" condition only compare across 2 concurrent loops? - I have some code that swithces a GA, and elsewhere I have code that is monitoring those same GA's (with a ONCE statement), and running code in response. There are occasions I want to switch those groups without the responses being triggered. - I'm thinking that if I just set a flag before I switch the GA, then in the response I'll test for that flag, then if set, just reset the flag and exit, - thus skipping that response for one loop only... Would I be correct in assuming that on the next loop the ONCE condition would not be true any more and thus would not run the response code?

Cheers all!

Paul G.

 

OK, so from trawling around some of the posts in this forum, Ive kinda figured out that I can use the touchscreen stuff in PICED to "simulate" my CBUS network... - So in theory, I can place CBUS switches on the virtual touchscreen, and operate them as if they were my physical switches on CBUS, and the logic will respond to these as though they were the real thing, - yes?

I've played about with that a little, and I seem to have virtual switches working with the logic... (although the switch indicators are a triffle hard to spot!) - Can I place something on the screen to show the value of a variable? - I'd like to be able to monitor the value of a counter variable that is being incremented in logic in response to button presses... - what component can I use to do this?

Many thanks, - and I promise I'll get the hang of this oneday!

Paul G.

 

Yes.

Yes

If you re-program a PAC 100 times, you are doing something very wrong. See below.

You should do ALL of your testing in PICED before downloading to a PAC. The debugging facilities in PICED are far more extensive than in PAC. You can either connect PICED to a C-Bus network and test it, or you can place components on a page to control C-Bus and simulate the C-Bus controls. Either will work well.

Not exactly. It looks for a change from the last time the once condition was evaluated. If you write code that means the once condition is skipped on a particular scan (like is being proposed below), then it will not be comparing with the last scan, but with the last time it was evaluated.

There isn't enough detail here to know what exactly you are proposing. You could write the code using a flag called IgnoreChange as follows :

Code:

once GetLightingState(group) = ON then
begin
  if not IgnoreChange then
  begin
    { do stuff }
  end;
end;

In this case, the once condition is being executed on every scan, so will work as expected. If you wrote the code like :

Code:

if not IgnoreChange then
begin
  once GetLightingState(group) = ON then
  begin
    { do stuff }
  end;
end;

then it would not work properly. See the logic help file topic "when to use if and once" for more information.

 

Hang on fellas!!! What is this 100 limit upload to the PAC?? Crackers!

Can I say that testing on a PC is uesless in my experiences, as everything works great on the PC, but when it gets transferred to the PAC, because it is slower than the PC, things just dont happen.

For example, I had a for loop that was turning some lights on, and when it was on the PC, worked perfect, transferred it to the PAC, and then it doesnt get all the way through the for loop (some GA's dont get switched on).

Also, since having my PAC, I would have changed the logic in the house at least 30+ times as we think of new things we would like to do...

Is there info on this 100 limit somwhere I can read about? Was never told this in our training courses *grin*

 

There are cases where everythings works in PICED and crashes in a PAC. And to identify the point where this happens, you end up placing some debugging code and re-loading the code into the PAC. I have done this a few times already. Not sure how many, does this mean once I get to 100 I am done, and I have to replace my PAC?

 

I too found that everything works in PICED but not when loaded to PAC.
I received my PAC a few weeks ago and then found out about the 100 limit!!!!

I had PICED using ONCE command to test when a flag it set and then turn on/dim lights etc and then turn them off after 5 minutes if the flag does not get reset.
This worked great when testing in PICED for over 1 week (had to restart the CBus connection after the 2 hour time limit tho).

When loaded to PAC, the ONCE command failed to catch all the flag change occurances.
Had to change code to use WAITUNTIL instead of ONCE command and now the code in the PAC works great.

I also had a other code tested in PICED that
Ran a Module
This module diabled another module
Ran a scene which turned off approx 35 lights
Enabled the module it disabled earlier

Worked great in Piced, put it in PAC and the PAC would

Run the module unitl after the scene completed, when it went to Enable the module that it diasbled, the PAC would reboot.

Total code for this and the modules above was less than 250 lines.

This took a few loads of code to the PAC tho to sort it out.
(The module to run the scene was REMOVED so the PAC would be stable)

End result, you can test all you want in PICED but that does NOT mean it will work the same as a PAC.

 

Newbie PAC Question...

Thanks for all the replies guys, - it seems I am not alone!

After a lot of trial and error, and thanks to getting the realisation from posts here that this is the way to go, last night I managed to sucessfully setup my PICED project so that I had a bunch of CBUS switches and groups being simulated. - I now (I think) have a pretty good idea of how it's architected conceptually. - It would certainly seem to be a glaringly obvious shortcoming in the documentation though... - Unless there's something else I haven't found (and I have been looking), then it seems to me that this information really isn't documented anywhere, and a newbie would have no way to come to this realisation...

Anyway, I've setup the groups etc. that I have been working with in my logic, and I now have the code doing exactly what I want in PICED. - It's more than a little bit disconcerting to hear others' reports of problems transitioning code from PICED to the PAC though... - I'll have to wait until the weekend and see what happens with mine..

Just out of interest, - why is this 100 transfer limit even there? - there's plenty of flash memory available these days that is good for several orders of magnitude more write cycles than that, - and no one could claim it's particularly expensive... - I just cannot understand why anyone would have thought this was acceptable! - what happens to PAC owners when they reach the limit, and can't transfer any more?

Cheers.

Paul G.

 

The same processor is used in the Black and White C-Touch and the PAC. When this processor was first manufactured, there was a limit of 100 erase/write cycles. During the last few years, the manufacturer's process has improved and it is now possible to do well in excess of 1000 erase/write cycles.

All C-Touch units made in the last few years and all PAC units will have the increased limit (1000).

To clarify my comment about simulating using PICED, the code will run exactly the same in the PAC as it will in PICED. The PAC can not run as much code as can be done in PICED. If you try to run too much code in the PAC it will reset, but apart from this limitation, the simulation should be precise.

We are not aware of any current differences between functions in the PAC and PICED. If anyone finds any, please let us know. Before you do so, just check that it is not caused by too much code. The status LED will tell you if the PAC is resetting.

 

I am finding that when I have logic that is checking a lot of GA's (its not resetting the PAC, I checked) that while in PICED, it detects my turning a switch on and doing something instantly after I have clicked that button.

When I have transferred that to the PAC, when the light is turned on, there is quite a pause before the PAC sometimes kicks in to do the logic.

Its like the PC is so much faster it can handle it, but the PAC takes longer to detect change across the cbus network, and respond to it.

Will post some code soon of things that are different in PAC V. PICED

 

PICED and PAC both run logic within 0.2 seconds of any changes. With PAC, it will take another 0.1 seconds before any resultant C-Bus commands are sent to C-Bus, whereas with PICED, the commands start coming out sooner. I would be very surprised if this difference was noticeable. By the time you allow for the C-Bus commands being sent and the filament lag in the lights, the difference between the two should be around 25%.

If you send a series of C-Bus commands, then that is a different matter. When logic send a series of commands in PICED, C-Gate concatenates several into one C-Bus message which speeds things up. PAC only does this for scenes, not for separate commands sent from logic. Commands from logic in a PAC get sent out at 5 per second. Is this what you are referring to ?

 

Darren,

It would be a really really big help if you could point me in the direction of some specific info on the concatenation of messages for C-Gate 'and' PAC.

Cheers

 

Well, I'm happy to report that my code has transferred and is running just fine in the PAC. I'm also quite relieved to see the 100 write limit is no longer an issue, - 1000 cycles should be *more than* enough! - 100 I could imagine hitting over the course of a few years though...

I would like to suggest though that some more emphasis be given in the documentation to the conceptual architecture of the logic engine in PICED & how it interacts with the PAC & with CBUS... - I noticed a small note in the project wizard that says "screen is only used for testing with a PAC" - but I never twigged what that actually meant. - It was only through this thread that I arrived at the understanding of how it works, and how to test PAC code using PICED. - Previously I had assumed that *all* the design stuff in PICED was only relevant to C-Touch projects, and had just ignored it. I started off thinking I had to transfer into the PAC every time just to test every little code change until I got it working... I must have wasted about 10 or so transfers into the PAC before this thread mad me realise I could test in PICED...

Lastly, just in case anyone's interested, the code I now have running is a sort of "smart" all on / all off button... - I have a 4 key input unit in my bathroom, 3 keys directly control loads in the room, the 4th key is an "ALL" button, but whether it is an all on or all off depends on how many of those 3 loads are on. simply, if there are more loads OFF than on, then the button is an all ON, if more loads are currently ON, then it is an all OFF. Sounds simple, but it has to always track the status of the other 3 loads, and adjust the status of the 4th button as the other loads change, so that the local indicator on the 4th button correctly indicates its current function... It works like a dream now, and wifey seems quite happy with it!

Cheers.

Paul G.

 

A new topic exists in the unreleased V3.7 FAQ which covers all this. I have attached an extract below :

Problem

Why does it take several seconds to execute a large Scene ?

Cause

Approximately 40 ON/OFF commands can be sent to C-Bus per second. If you have a large scene with 120 Group Addresses, it will take up to 3 seconds to send all of these commands.

When C-Bus commands are sent by the PICED software (from Scenes, Schedules, logic and button presses), the commands are placed in a queue, then sent out in order as fast as possible.

If you execute several scenes in quick succession, sometimes you can get unexpected results. Consider the case where you set a scene which switches 120 Group Addresses ON, then immediately set another Scene switching those same Group Address OFF again and then immediately set the original Scene again. You will have 360 C-Bus commands in the queue which will take around 9 seconds to be all transmitted to C-Bus. During those 9 seconds, you will see the Group Addresses go ON, then OFF, then ON again. This is normal behaviour.

When a Scene is set, the Group Addresses on the PICED screen will show the new state immediately to provide immediate feedback. There will be a brief discrepancy between the state shown on the screen and the state on C-Bus.

If you set a large Scene and one of the Group Addresses has a short pulse, you may find that the pulse duration is changed. Consider the case where you set a Scene with 120 Group Addresses and the last one has a 2 second pulse. The 120 C-Bus commands get put in the command queue. 2 seconds later, the "falling edge" of the pulse is added to the queue. At this stage, the queue still contains 40 commands. You will end up with the falling edge of the pulse being straight after the rising edge of the pulse in the queue and so they will be sent out very close together in time.

In the PAC and C-Touch, C-Bus commands sent as part of a Scene get concatenated together. As many as 8 on/off commands can be sent in a single C-Bus message and 5 messages can be sent per second, giving a total of 40 on/off commands per second. Commands sent by user button presses in C-Touch or by SetCBusLevel commands (and other non-scene functions) in logic in the PAC do not get concatenated and go out as single commands. This means that if you are sending individual C-Bus commands from PAC logic, you can only send 5 commands per second.

 

We have been assuming that this sort of information would be conveyed during the logic training course. I will add some more about this for those people who haven't attended a course, or who fell asleep during the course ;-)

Good to know that the forum is being of use.

You may want to post part of your code on the logic code forum so we can all benefit from your hard work.

 

It is great

 

How do you know that you have reached it?

So how would one know that they have reached this limit?

 

Talk about digging up an old thread!

The unit stops working, quite literally. When a bit gets stuck in the wrong state the memory checksums will fail. Exactly how it fails will depend upon where the failure in the memory occurs, but you can be sure that you'll know about it. In all my years I've never actually seen a PAC flash fail.

To get to 1000 cycles you'd have to be re-programming the thing every single day for 3 years straight... and that's dedication.

The manufacturer states that the flash lifetime is guaranteed for more than 1000 cycles. How much more than 1000 could be anyone's guess and depends on lots of factors such as temperature, time since last programming, etc etc. Yours might last for 10,000+. You are welcome to try in your own time.

 

I have had some instances where i have been using the in-built system IO of HVAC, whilst 'connected' to c-bus these system bits in piced do not accurately (if at all) reflect the status in PICED.

To explain further; a dummy page was created in piced, with no change in status while in the real world things seemed to be happening, as i was trying to debug from the PC (not the touch screen) the status of these bits were not updated on the PC but after numerous attempts i then walked over to the touchscreen, and on the touch screen, they indicate status just fine.

I probably killed 5-10 transfers altering the code because i did not think things were working as i would have liked...

Might be worth looking into.

Cheers

Grant

 

If I read this correctly, you are saying that components using HVAC In-built System IO in PICED were not showing the correct data.

There are a few things to check:
1. Look in the log to see if C-Gate is receiving the expected messages
2. Make sure your components have the correct Zone Group and Zone numbers
3. Have a look at the HVAC manager (Project | C-Bus Applications | HVAC Manager menu item) and see if there is valid data in there.