Using Receipts as part programs in Display

I am working on a machine that uses “part programs.” The part programs would consist of data that commands the machine to perform certain tasks. Does anyone have any suggestions on how to accomplish this? Examples?


Hi bzmachine,

Welcome to the forums! Sounds like you have an interesting application. I’m not completely clear on what you’re trying to do, and would encourage you to share a few more specifics if possible. In the meantime, here are a few questions and suggestions that might be helpful to ponder:

  1. Are you already using PAC Display, or are you considering using PAC Display just for the recipe feature? I ask this because there are other ways to graphically display your data, and if you now or at some point in the future use one of those (rather than PAC Display) it might make sense to consider some options that are not PAC Display specific. For example, here’s a GUI option you could hold in your hand:
    GUI Option

  2. If you’re set on using PAC Display and the recipes seem like a good fit, here are some relevant links that might be helpful:
    Tech Tip on variable initialization
    Recorded webinar on using Recipes

  3. Consider using pointers and/or subroutines. I know these are kind of “advanced” but sometimes they’re not as bad as you think, and can make doing [B][I]similar logic using different sets of data[/I][/B] a whole lot easier! (I think that’s what you’re doing. Is that correct?)

Here’s another discussion which might relate if that is what you’re doing:
Subs and Pointers

Also, in case you missed it in the most recent OptoNews (be sure you subscribe if you’re not already!) this video talks about using one little pointer table to make code re-use much easier:
Three Steps to Maintainable Code

[/INDENT]Hope that helps give you some food for thought. The more details (or big-picture views) you can share, the bigger the brainstorm we can get going for you here on the forums.


At this point I believe that I will continue with the PAC Display software. The part program is just a matrix of numbers see below. The user just needs to enter to the data and then save it with specific name so that it can be saved and reused at another time.

X – Y – Z
2.5, 1.7, .45
5.2, 3.6, 2.5
3.4, 7.4, 3.6

Sounds like you need some tables. Our tables are one-dimensional so you’d need 10: one for the name, and 9 for each element of the 3x3 matrix.

For example, you might name the tables something like this (if you follow the naming convention where the “nt” prefix means integer table and “st” means string table as mentioned in form 1700):





The length of each table would be how many of these matrices you’d ever want to store. Index 0 of each table would correspond to that record (or perhaps part?) index.

How many do you have in mind? How would you want the user to see/enter the data?
Your options are many, here’s one using the table from PAC Display configurator’s toolbox (see below).

Here I’ve just shown lucky 22 parts, would you have a lot more than that?