Best Practices -- We'd Like Your Feedback!

PAC Project
1

Hello OptoFans,

We’re working on a new document to help Opto users both new and experienced to improve their projects to be more maintainable and successful overall.

We’d love your feedback on what’s in here and suggestions for other topics we’ve left out. Currently, the topics we cover fall under: Building, Documenting, and Backing Up your projects.

What else to you wish you’d known about before as a newbie, or currently puzzles you that would fall under “Best Practices”?

Do share! Here’s the draft: Draft Best Practices document

Thanks,
OptoMary

2

After reading the doc, the first thing that comes to mind is debug…

Perhaps after the section on page 11 ‘Backing up your project’ we should add a section about getting into debug mode.

One of the things I had to learn as I worked with PAC Control was how important it was to backup my strategy in such a way as to be able to be able to go into debug in a moments notice.
Let me explain.

If you discover a bug in the machine/process behaviour, you need to be able to go into debug to see what part of the code needs tweaking.
If you have made changes to the code since the last download, you will get a warning if you try and go into debug mode, the warning is correct in what it says… The code that is running will be stopped and replaced with this new code.
Once you do that, the new code will start running from the power up chart, block 0.
Suddenly, the erratic behaviour is cleared up and the process starts anew… What caused the bug? You don’t know, you have to wait till the process get into the buggy condition again. It could be minutes, hours or even days before all the conditions are just right.
If on the other hand, you have a backup of the strategy that allows you to simply open the strategy and click debug and go straight in, then you can look and see what is causing the errant behaviour.

Like most things in Opto, there are a few different ways to reach this ‘instant debug’ goal.
What we did at the hospital is as soon as we did a download, and we were happy with the code, we closed PAC Control, (You have to close it, it makes a lock file which you can’t copy when its open) opened up Windows Explorer and copied that strategy directory to another sub-directory we called ‘debug’. This code was then frozen.
No one touched it.
If we wanted to make changes to the code, we did it to the original strategy that was in another location.
Another way of achieving the same thing is to have the ‘debug’ directory, and upload the strategy archive to that location, unzip it, compile it and then go into debug with that strategy. This of course assumes that you have created and downloaded the archive to the controller.

The end result is the same, the coping is just quicker.

Point is, I feel that you MUST be able to enter debug without having to do a download.

I feel so strongly about this that its not a ‘best practice’ in my mind, but a REQUIREMENT!

Ben.

3

Ben, that’s a good point…we keep all of our code in a repository (git), so it’s easy for us to check out an appropriate version to debug code that’s on a production machine without downloading a strategy. I really like having the repository for backups (no more folders labeled “Project 1 - old”, “Project 1 - old old”, etc!) and documentation (we also integrate it with ticket tracking).

Everybody has their own preferred method for these things, so I don’t know if that’s something to put in the best practices document, but it might be worth mentioning for people not coming from a software background. Some of the benefits of typical repository usage (i.e. diff) are lost because the PAC Control files are binaries, but it still is a very useful (and free!) tool.

1 Like
4

tricia,

Gold! Thanks so much for this feedback.
I took a lynda.com lesson on [URL=“http://git-scm.com/”]git a few weeks back with this very thought in mind, but the fact that PAC Control files are binaries put me off.
Now that you have told me that you have it up and running and that its useful, I will revisit the subject.

Thanks a ton!

5

There was also this previous discussion where we mentioned version/revision control and Subversion, and I suggested one way to get a bit of a text file that could be helpful for a diff.

Source control was one of the topics that landed on the editing room floor for the first draft of this doc, but perhaps we shall put it back in for this trick. Thanks, all!

6

Thanks for your feedback! In addition to this thread we received email suggestions from some of our most experienced distributors, integrators, and customers. We incorporated a lot of this material and the latest version of the Best Practices tech note is now available: Best Practices for PAC Project and groov.

7

Jean also shared this interesting article on comments, and what they should/shouldn’t include, click here.

8

There may have been a discussion about this sometime before, but my search skills aren’t working well today. Is there a best practice for using booleans in Pac Control / Pac Display?

Using int32’s allows each “boolean” to have its own name, at the expense of wasted memory. Also, there is disagreement between what it means to [B]Set[/B] an int in Pac Display (set = -1) vs [B]SetVariableTrue[/B] in Pac Control (set = +1). This makes testing for equality a little clumsy.

Using each bit of an int as its own boolean is an option that plays well with the bit commands, although I’m not sure there is an obvious way to give each bit a name or point to it in a way that makes the code is clear. Have others found a clean way to use booleans?

9

Hi sensj,

Here’s a link to that previous discussion (also shows where you can choose a +1 or -1 value to be sent, in newer versions of PAC Display).

Don’t worry about using memory. These days, you have plenty! Here’s a link to a doc that says exactly how much: Form 1646 Memory Usage Tech Note.

If you need another reason, (named) Integers also work better for groov (vs. trying to use a bit within an int or int table).

Are you doing any reading/writing directly to the memory map? That’s about the only time I can think of where you’d need/want to use a bitmask.

-OptoMary

10

Thanks, that is the discussion I was looking for. Weird that searching “true” in the Optosearch (restricted to forums & blogs) didn’t turn up that thread. I have been able to avoid any direct interaction with the memory map, so using int32’s and adjusting PacDisplay to send +1 will work well for me.

11

Yes, for some reason google with

site:opto22.com/community

works better. For example, to find the “true” link I shared above, I did this search:

SearchOPto22.png802×271 18.8 KB

I also used a similar search to find this similar discussion on searching: :slight_smile:
http://www.opto22.com/community/showthread.php?t=270&page=1

Hope that helps!
-OptoMary

12

To Whom It May Concern:

  I have read the "Best Practices" document.  It was a good read.

  I would like your next document to show the beginner programmer how to save files for portability.   I noticed that when I open a program in another computer, the program in the current computer may not run correctly because the program is looking for files that it can't find.   There appears to be a fixed file structure that will exist when you save a program.   

  This file structure is something that I am not used to.   I have programmed in C, assembly language, and other languages, and usually once the file is created (eg. I created an *.exe file) there are no problems running the program on an external computer.   

   Can you advise to the best method to save programs for portability (eg.:  "relative" file locations?)?
13

hi Tricia Could you shared your Setup for GIT?