Locking Text in editable text field

I am trying to create a user interface for an engineering test. The engineer needs to be able to input information into a text field related to specific sensors. These tests run for days. The text and the test data need to be written to the database together. The only data being recorded is the completion time of the test and the text.

My thought was to trigger the table input when the sensor goes high (the test is complete). The problem I am having is after the engineer inputs his text information through the PMI window and closes the window, the text fields do not retain the information.

I know someone has an easy way of doing this that I am just missing.

What do you think?

I don’t think I understand the sequence of events here - what is happening where/when?

FactoryPMI windows do not retain state. You have to put any information that you want to be persistent somewhere, like in the database.

I have a window for the engineer to start and monitor a test. The test is a simple process. items are set and then timers are started in the PLC. Once the items open, sensors read that and stop the PLC timers. I need to record those time values along with information specific to the particular test that has to be input by the engineer.

I have created text fields for the engineer to input his test particulars, start the timers, and reset the timers after all tests have ended (up to 10 tests can be run at the same time).

Maybe I could write multiple entries to the database - a test start and each test end. Then I could manipulate the visibility of the text. Before the main timer has been started, the text entry fields would be visible. Starting the timer would trigger the data to write to the table. After each test ends, all values could be written again. As long as the timer is running, I could have a text label display the text for that particular test. After all tests have finished, the data could be exported to Excel. When the main timer is reset an entry could be made that shows the reset so I would have a search point to separate the tests in the database.

Would this work? Is it a clean approach to the problem?

Thanx.

Does the operator always enter the information before starting the test? If so, the following might work:

  1. First off, there is a table that FactorySQL is recording the values to. Each row will represent a test. There will be an extra column for the test notes.

  2. To start a test, the user inputs the information, and hits “start”. FactoryPMI inserts a row into the data table, with just the note data for now.

  3. Right now you probably have the FactorySQL group set to “insert” a new row into the table when the end condition is triggered. Instead, set it to update the LAST row of the table.

So, the sequence of events:
-User enters notes, hit’s start.
-FactoryPMI inserts new row into table, with note data
-On finish condition (set in FactorySQL on the group’s trigger tab), the group updates the last row with the new data.

That’s the simple version assuming one test at a time. To get fancier, I would do the following:

  1. Have a FactorySQL group for each machine/concurrent test run
  2. Add another column to the table, called “machine_id” or something that makes sense.
  3. Add an action item to the group, set to always run (ignore trigger), which performed a query: “SELECT tablename_ndx FROM tablename WHERE machine_id=1 ORDER BY tablename_ndx DESC”
    Notes: tablename is of course the table, and the “machine_id=1” is different for each group. Just assign each one a number, doesn’t really matter. This query is getting the id of the most recent row with the given machine_id
  4. Change the group setting from “update last” to “update custom”. In the where clause box, enter “tablename_ndx = {actionitemname}”, without quotes, and with proper names. Note that you can right click or hit CTRL-Space to easily get the item reference.
  5. In FactoryPMI, change your “start test” button to insert the test data, and the machine id that you’re starting.

Might look a tad complicated, it’s just that you’re allowing for multiple concurrent tests, and the groups are looking up the id of the row that represents the test they’re responsible for.

Hope this helps,

Thank you, Colby. I will give that a try and let you know how it turns out.