During the final system test...

[Deleted User]

It is always a good idea to Enable Diagnostic Messages in Studio when final testing any program. Often you will find run time errors like 'zero index reference' to an array.

I do this when pushing each touch panel buttton during the final check out before leaving a system to the customer.

Make sure to test the Define_Start section as well. You need to be quick in enabling diagnostics after a reboot.

Also, simulate a power interuption to see how the entire system (including controlled components) will behave. I have gotten into the habit of always putting the control system into a known state upon reboot. This includes, but not limited to, powering off components, clearing A/V routing, refreshing all touch panels, and resetting program variables.

Any other good ideas?

NMarkRoberts

msg on

B_Clements wrote:

It is always a good idea to Enable Diagnostic Messages in Studio when final testing any program.

I *always* have a telnet session running with "msg on" and once in a while during a reboot I will reconnect as quickly as posible so I can watch what happens on startup. This way you very quickly pick up runtime errors and can save a lot of debugging time by fixing the runtime errors before you start fixing any behavioural errors that might be caused by them.

"What about screen real estate?" You might ask. Easy: second hand 21" CRTs cost AUD150. I have two. My desk is groaning but they light and heat the room nicely! In this day and age anyone trying to write complex coptrol systems code through a 1024x768 portal is crippling him or herself unnecessarily.

BTW a tip for repeatedly establishing a telnet session without all that typing:

Start / Run 'cmd'
Find out which directory you are in
Create a txt file in that directory called "a.bat" containing your telnet command eg "telnet 192.168.0.100"
Type a<enter> in cmd.

DHawthorne

NMarkRoberts wrote:

"What about screen real estate?" You might ask. Easy: second hand 21" CRTs cost AUD150. I have two. My desk is groaning but they light and heat the room nicely! In this day and age anyone trying to write complex coptrol systems code through a 1024x768 portal is crippling him or herself unnecessarily.

I do the same; I feel handicapped when I don't have my second monitor connected. What I really would like though, is a rig like this: http://www.matrox.com/graphics/en/gxm/products/th2go/gaming/home.php .

alexanbo

If you look at the log on the Master it shows all the stuff that would come out with msg on, so you don't have to be super quick at startup to see what's going on at startup.

GSLogic

I always have my 10 year old son test it and then if I really want to put the system to the test... I have my wife try it.

Believe it or not, in a large home system my son can really find programming bugs. I would never think of push some of the combination of buttons that he does. He isn't that bad at programming either, they learn fast!

JohnMichnr

A number of years ago I did a system that had the ultimate tester. The company I was working for was shooting a corporate marketing video, and it ended with something like - the company builds systems so easy even our CEO can operate them. Then they cut to a shot of a monkey in a suit pushing buttons on the touch panel.

Of course the Monkey pushed a sequence of buttons that locked up the system. I got a call the next morning to come down and re-boot the system and get it back online. I had to go back to the video to see what the Monkey pushed to lock the system up.

As it ends up the Monkey pushed a couple of buttons that I would have never assumed anybody would ever press in that order.

Teaches me to assume...

yuri

Offcourse you have to stress test your system. Problem is that most end-users (in my case) don't have any experience with this type of systems, and are often even affraid of it.

Most problems i come across have something to do with a lost wifi link (try to solve that) or locking up equipment. Problem with those errors, is that you aren't going to find them when testing, because your test environment is almost always flawless.

Pressing a random number of keys will certainly get the most errors out, but you can't find them all until you get to the jobsite and do your final system check

DHawthorne

I have put out a standing request that my systems all be tested by someone besides me after they have gone live. I simply cannot get my head out of the patterns I built into the program sometimes, and an fresh, objective treatment will often result in not only a more robust system, but one that is easier to use. And after that, I tell the customer to take notes on the things they either have discovered to not work quite right even after our testing, or they would just like to change around; then I go back a week or two later to make adjustments.

I find myself repeating this like a mantra: "This is a custom installation. We have done everything we can to insure it is working properly, but the fact that it is completely unique means that there may be a minor bug we haven't noticed, but will only show up after being used on a day-to-day basis. We remain committed to ironing all these bugs out, so don't hesitate to report them when you think you have found one."

Often, customer-found "bugs" are really just things not working as they expected, though they work entirely as I intended. I'll explain my reasoning, and let them decide if they want it changed or not. This kind of flexibility doesn't come cheap though, and you have to build it into your pricing.

yuri

i think you HAVE to be flexible in this business DHawthorne, and doesnt really need to be built in to the prize...

DHawthorne

yuri wrote:

i think you HAVE to be flexible in this business DHawthorne, and doesnt really need to be built in to the prize...

Yes on the first, but if you don't allow for it in your pricing, too much flexibility and you go broke. Perhaps I wasn't clear, but what I was getting at is that you can't afford to charge for 100 hours of labor, and then offer free adjustments that run into 500 hours, unless you charged 5 times what you needed to make for the 100 hours in the first place. There is always a certain amount of fudge and free stuff in every project, and the larger the bottom line, the more of it you can accommodate, but sooner or later you have to cut it off or go out of business.

[Deleted User]

DHawthorne wrote:

I have put out a standing request that my systems all be tested by someone besides me after they have gone live.

This is such a great point.

Every writer needs an editor just like every NetLinx programmer needs a button pusher. I believe this should be the person assigned to train the end user on system operation and functionality. Sometimes this is the salesperson, but I prefer the project engineer or project manager.

What bothers me is when the button pusher verbalizes what needs revising instead of providing a written list.

JohnMichnr

DHawthorne wrote:

I have put out a standing request that my systems all be tested by someone besides me after they have gone live. I simply cannot get my head out of the patterns I built into the program sometimes, and an fresh, objective treatment will often result in not only a more robust system, but one that is easier to use.

All monkeys aside:
I have to agree completely - I find myself pushing the same buttons again and again, because I wrote the code and know how the system is supposed to work, according to me. That is not necessarily the way the customer wants it to work. I always want somebody else to push button on systems just to watch how they would go through the system, and how that differs from teh way I would go through the system.

As a sub-contractor though I am finding it harder to find anybody to do that. There seems to be a growing trend that the programmer is the last one on the site - so they have to test the system. Often times I find myself spending more time pointing out video wiring problems than I do getting input on the touchpanels.

NMarkRoberts

B_Clements wrote:

What bothers me is when the button pusher verbalizes what needs revising instead of providing a written list.

Some people communicate well in writing; some don't. The latter evolve to become software users. No idea why.