B&W CTouch Error Diagnostics

Hello C-Bus People,

I have a project I am working through testing of and would like some clues as to what degree of problem I have with the level of network errors the C-Bus diagnostics tool is showing me.

The project does not generate the errors when I run it from PICED on the laptop, but when I install it to a touchscreen I see a steady cycle of periodic errors. I do not observe any other problematic symptoms; from a functional perspective the logic runs and does what it is supposed to.

When the errors are occuring I am not seeing clues within the Toolkit application log. I read this as meaning it is a factor of 'behind the scenes' system messages and not necessarily directly to do with actual logic instructions I am issuing.

My question then is what types of things can I check for to get to the bottom of what is causing the errors, and what is 'normal' in terms of acceptable error rates.

I have checked the burden and checked that I am not polling light level sensors which are not physically present. If it is a direct result of code I have written, I think it must relate to some commands which do not appear in the toolkit application logger.

Thankyou in advance for any insights or observations.

Regards

Steve

PS I must say that I am very impressed with the MARK II logic engine and its capabilities, an amazing product so well done to its designer/developers.

 

The most likely cause for this sort of thing is the C-Touch trying to interrogate another device on the network for information when the other device doesn't exist at the target unit address. I know you said that you've checked to make sure you're not polling a light level sensor at a missing unit address but I'd keep looking in that area.

Any monitor component that can't find it's target will result in communication errors showing up on the network. This is because the commands sent from the touchscreen to the missing device do not get acknowledged. The touchscreen retries a few times, resulting in the spike in message error rate you're seeing.

Messages that poll other units don't show up in the Toolkit application log.

The other clue that it's related to a Monitor component is that the burst of errors looks like it's happening about every 20 seconds. 20 seconds is the default update interval for Monitor components that poll other units.

Take another look at all of your Monitor components in PICED. If any of the target devices are not present at the specified address, you could expect to see what you're seeing. It might even be something as simple as you specifying the unit addresses in decimal in one place and hexadecimal in another. Worth checking.

 

Success

Thanks Newman,

You were right first time, there were three monitors I thought I had removed. Once I removed these the periodic errors stopped happening. Thanks for the advice.

If there is any further advice on how to interpret the various diagnostics tools, logs and logic engine resource window to enhance the stability of my project I would be most appreciative.

e.g. RAM Stack Min/Max 54/57
Program 16%
Run Time (last/max) sits at around 3%/4%

On the run time last/max I have observed the occasional peak of up to 14%. The approach I have been taking is to rework sections of code to try to keep the max below 10%. Am I being overly cautious here?

My resources report tells me that I have used about 50% of the available resources, once again I have an approach of giving the project a workover to keep this at around 50% if it starts creeping up.

I have implemented much more code and functionality than I expected to be able to fit into the Touch-screen and I am asking myself what signs to check for that I am approaching its limits.

Regards

Steve

 

Loigc Resources

Hi SBL,

You have room to move here. The important values are the average run time and the max.
If you hit the max on any individual logic cycle then you will get an error and logic will be re-initialised. You need to take care here, but 10% is fairly cautious. Other than huge sections of logic code, the main user of logic processing time is setting large scenes, so be careful if you are using huge scenes from logic.
B&W touchscreens will let you run a long individual logic cycle, but they cannot all be long. The idea is to let a lot of logic run when required (e.g. to set a big scene, process an event etc.), as long as the average is under control. For B&W touchscreens, if you keep the average run time under 50% you should be OK.

How much of the code space you use is not a performance concern for Logic. Increasing this above 50% should be no problem, as long as you keep an eye on that average run time.

It's great to hear the product is exceeding expectations!
The easiest way to confirm if your project is OK in the real world is to run it for a while and check the Logic Error check box on the Diagnostics page. If there is a logic error of any kind this check be ticked. If the tick box is clear, then you're OK.
Average and peak run time are the key factors here and it sounds like you have them well under control, so i don't expect you will have any issues.

I hope that helps!
Mark.

 

Thanks Guys

Thank you for the prompt feedback and guidance.

The product has exceeded expectations. I put this down in part to going to great pains to do things by the book, and in part due to the availability of expert technical advice and guidance through this forum and the Clipsal technical support channels.

Regards

SBL