I am attempting to figure out the easiest way to combine two buttons:
Current Workflow:
1 - Operator presses a graphical button in order to trigger a string entry dialog box, enters test name, confirms with enter / ok
2 - Operator presses a graphical button in order to trigger a recipe download, which starts my test chart
Desired Workflow:
1 - Operator presses a graphical button, in order to trigger a string entry dialog box, enters test name, confirms with enter / ok, test chart is started
Anyone have suggestions for easiest way to get from my current to desired workflow?
I need to start a chart after the operator enters a name for the test, which is needed to set the log fileās name before the test starts. Iād like to go immediately from entering that string into starting the test chart.
The way I accomplished starting a chart via Display (to-date) was by downloading a recipe with a start chart command, I have not seen another more efficient way of doing this yet, and am open to suggestions. The recipe download is only my current means to an end. Said another way, I am not doing anything else with my two recipes (one simply starts the test chart, the other simply calls the wrap-up (stop) chart).
You should be able to set the run āstateā of the chart from PAC Display. If I remember correctly a 3 set in the state will make that chart run. In this case the name of the chart was bid4
Correct, my first attempt was to simply combine the buttons and see if the two commands executed in parallel or series. Unfortunately it is parallel, so my chart starts immediately
Thank you Norm that gives me a second, and I think preferable way, to control a chart from Display. I was not liking having to dip into recipes just to execute a single command.
But I believe I am still stuck where I cannot wait until the prompted string (log name) is entered, THEN take action to kick things off
Before I posted I was considering exactly that to be my only known alternative. I would like to avoid having a chart and loop polling constantly and waiting around for user input if I can help it. I did that with my first couple strategies in Opto this past half year, didnāt like the effect it has on my strategy flow
You do bring up a good question though: is there any way to sort of go in the other direction, and have the newly started ātestā chart let Display know it needs string entry before it proceeds - is there conceptually a way to tell display you need a string prompt to pop up?
Final note for the night, this change request came from my operator today, as he is used to our legacy software being a bit more foolproof. Today he named the test correctly but forgot to start the actual test/logging. Heād prefer that you canāt start the test without first being forced to enter the log name, AND not have a way to change said log name any way besides that.
I can totally see his point, as Iām familiar with the legacy software heās referring to, and I actually do like the suggestion, Iām just stuck with how to go about this Correctly
Leave the chart running (start in your power up or wherever necessary) and then have a check in the chart to see if it is time to run your process. This shouldnāt affect your strategy flow and is a pretty standard thing. Just make sure you have that delay in there - a second should do - and the rest of your strategy wonāt even notice.
See below for the basic flow of what I am talking about. Your current chart you are starting would be where the orange block is.
It is very helpful for me to talk (type) things through like this and make sure I am approaching each ānewā task appropriately. Iāve found it is much easier to learn the intent of how some of this was designed instead of trying to apply conventions from past coding lessons Iāve learned (gross example: my first PLC code I attempted to create functions within the ladder logic instead of learning the core concepts of ladder logic )
If you are concerned that the operator remember to enter a string you can set a integer variable at the top of the chart (ie. nWarningFlag) that is used to make a graphic visible on the HMI. This variable is assigned as a visibility dynamic attribute to the graphic. If you make the graphic large, annoying and flashing it usually gets the operators attention. Then when your chart sees the string has been set (no longer blank) you can clear the integer flag variable which will make the graphic invisible.
On another thought if your test data is important, have you thought about writing the log file on the controller rather than through PAC Display?
If PAC display were to crashā¦ your data logging would stop, If instead you write a log file to the controller and then let the controller send it via ftp when the test is over you might have a more reliable and flexible solution.
In essence you set up a communications variable that names the file you want to write to. This file can be stored either in the controllers local memory or on the microsd card (recommend if there is lots of data). Because the communications handle is a variable you can set the file name as you wish. Then you can build the string of data that you want to write to the file. These can have multiple rows and you can use Date/Time to start each line if you want to. Because PAC controllers have a ftp server built in you can āpullā the file from the controller or have the controller send it. You can also open the PAC file as a network FTP source in excel and read the data in directly. Lots of options built on industry standards.
I have had a few applications that have required a āPAC Displayā chart. It simply handles the GUI requirements of the display and interfaces with the other charts in the controller as needed.
There is nothing wrong with this approach and is often better than trying to force/compromise PAC Display or user gyrations to get the display to work as desired.