The table widget in Pac Display needs a means of selecting the row by an operator.
In other words as an example, I am getting a file via ftp from the MicroSD, and importing it into one string table. This is a CSV file so once the operator has scrolled through the string table (1000 elements long), he needs to be able to select a record in the table which would load an index var in order to parse all the columns into string, integer, and float value variables.
So to summarize, the table object needs a check box to allow selecting the index field of each record and write that index value out to a var. The index field would show up as a push button with the index number on it.
I came up with a work around, but it is no where as clean a solution. I placed a vertical bar on screen which an operator slider, then a set of 5 index vars lined up vertically, which read out the current index value scrolled to. Then in five strings, the part number column next to the index numbers are displayed of the string table. Then I have a up and down push button that scrolls the index numbers up and down in order to search for a part number and have 5 values displayed in any part of the table. Once the operator picks on an index button, it writes the index out to a var, and another function parses only that string into the parameter values for operating the process.
Don’t get me started on View…hehe. Start with the “what would you like on view” post.
Best possible thing Opto could do would be a web based version of Pac Display that has all the current features to start with.
I will when I get a chance next week.
Working on a Prover, proves flow meter accuracies automation style. It has an 8" cylinder driven by a 14 hp Kollmorgen drive that provides flow rate and a API certified counter system for proving the counts accuracies. Not to complicated, but there are a few moving parts…
A picture is worth a thousand words… I am trying to visualize what you summarized here.
How close is your current work-around to this summary?
Are you looking for a ground-up rework or a tweak?
Beno,
Thanks for quick response.
You have it about right. The idea is simply to make a single selection at a time from a table.
Since the table object works really well for scrolling through 1000 elements, and it automatically provides scroll bars as well. All it needs is the capability to send the index value of the element selected out to an integer.
This could be a check box enabled in the config.
The other possibility is where the current drop down box allows it to be tied to a table. It would need to be tied to either string or integer (possibly float) table.
It would also allow you to select (as it does now) but would write the index value out to an integer vars.
I would have considered using groov but this app is too fast and too big for groov.
I also considered using Excel but there are too many possible issues doing that for the whole project. With both it would be too messy.
With the changes I mentioned here, it would work great.
I am looking for a tweak, but I am all ears. Ground up will work if you’re only talking about the selection portion. Too much work on the rest of it.
I see I did not answer this. It is working but too clunky. Operator has to scroll down through up to 1000 elements to see the part number he is looking for. I do this by importing just the part number column into a string table, then I display five contiguous string elements at a time with the index numbers next to them. Each string element is actually moved to a string var in order to display and allow operator to select it which writes out the index number that I use to load that entire record into separate variables to be displayed and acted on. The scrolling logic works but is somewhat clunky, doesn’t operate smoothly.
I did not try to do a lookup based on operator entering part number, because it will have to loop down through entire 1000 element list each time to do a string to string element compare. Actually, this might be method I end up using as I suspect that it will probably run faster than I was thinking, especially if I used the new controller to test it…
The PAC Display dev and I mulled this one over and have two thoughts:
Have the operator scroll the full 1000, once they find what they are looking for, they tap a button at the top of the screen to enter the index number where they found it. ie, get the operator to just remember the index where they found the part number and type it in manually.
Exactly what you said in the second part of your post just now. They enter the part and your strategy loops through looking for it. The longest loop time will be if its the last element, so it will only be the worst case once in a thousand. (And honestly, even on a SNAP PAC, it might be quicker than you think or, at the very least, quicker than manually scrolling).
Even on an R1/R2, this would probably be fast enough to seem instantaneous. If the list is sorted, then it can be very fast. Barcode readers may be an option as well.
Well I agree, bar code would make most sense, but I donlt think they are there yet.
Also, the reason I did not go this direction in first place is the alpha-num list is sorted but not sure it would easily be looked up, figured there would be issues. In past I have made lookups that looked for first char, then second char, etc.
I think you are both right, probably should have done it that way from the start, at time I was under crunch.
This would be good test for new controller.