Above I gave an idea.
Run a gateway timer, not a transform on a view, and pull the data you want, via readBlocking, and get it into a dataset tag.
Then when you have a tag that is a dataset of all your data, then you can have a table that is bound to that dataset tag that will display your data.
Yes but that table would be so long and will have all the values in just one column. But I have to display it in a matrix form like the table of 62x47 columns.
Are you able to add free 3rd-party modules (that is, not Edge) ? If so, consider adding my Integration Toolkit. Constructing a "live" dataset to drive a table is relatively efficient with its functions.
Also, does your array start at subscript zero?
You can read all the tags as one list, then process that list into the multiple columns and rows as you need to display, and then write that as a dataset to a tag.
Ok good idea. Checking on it.
is it just for display purposes, or do you need any interaction on these labels?
i suggest plain text to display this kinda numbers, even svg's wont be nice if it has to update so fast. with the markdown you should be able to generate some kinda grid structure even with plain text
It's already an array, you can simply read MatrixMD04 to get all 3060 values in array form. If you install my module, put this expression binding on a table's data prop:
unionAll( // Build a dataset
forEach( // 47 columns of integers, named _0 to _46
47,
asMap(stringFormat('_%d', idx()), 'I')
),
forEach( // list of rows from groups
groupBy( // fan out the data by column
{[default]EchelonSinglePage/MatrixMD04},
idx() % 47
),
it()[1] // extract the row from the group.
)
)
Every time the PLC delivers fresh array data, the table will update.
Make sure you installed the latest. Should be version 2.0.15.
i would just display it as text and format the spacing a bit
if values go above 99 you'll need rjust(3), if its all just 1 diget you can remove the rjust
input is the long array without colums
n = 47
matrix = [value[i:i + n] for i in xrange(0, len(value), n)]
return "\n".join([" ".join([str(y).rjust(2, ' ') for y in m]) for m in matrix])
textgrid.zip (101.5 KB)
if you want it to appear like a grid, just setup a background img or something.
dont use 100ms refresh tho xd
The beauty of an expression like mine is it updates when the tag updates. If the OP can get that to update at 100ms, the display can follow.
yea i was mainly focusing on the text display, not the script.
displaying just text would be a lot more performant than all those labels
So I managed to display the array on a table with 60 rows and 51 columns and it is showing the values too but there is a delay of around 100ms - 150ms.
On the OPC client I have subscribed the tag array with 100ms but I cant go lower than this.
Can I go faster like a HMI lower than 100ms?
Are you using Ignition's native driver (classic GET/PUT) or the PLC's OPC server? If the latter, you are probably stuck with whatever minimum interval it allows.
If using IA's native driver, you may be able to make it go faster. Possibly only if that tag is the only thing you are trying read.
(Going as fast as you are attempting is very hardware dependent. Most such applications use an I/O protocol, not a tag-based protocol.)
It must be the PLC's OPC server because the tag he's referencing is an array...
Yes I have enabled OPC server on Siemens S71500 and reading the tag through OPC client of Ignition.
But I have also connected the PLC to Ignition using the siemens driver but I could not find how to address the array datatype. On the Ignition Manual for siemens addressing I found these data types only
I have array of Integer so my addressign would be
[Siemens S71500]DB67,(Here I did not found how to link the array)
For this huge amount of data, is it really critical that the display is delayed a bit?
Noone is gonna notice the difference in all those numbers so fast.
Make sure that your table polls slower towards your fast tag, so that it doesnt run into flooding issues
The driver doesn't do arrays, but it would still (relatively) efficiently read these points because they are contiguous in memory.
I think reading the single array tag via OPC UA is probably a better fit in this case.
Actually the purpose we are trying to achieve is to see the behavior of moving parcels on the conveyor. When the parcel passes through the barrier of Photocells (60 photocells) it generates a array of depicting the position of parcel. It is required for creating logic.
