Hi, i have enabled tag history for some string values, that are in a struct, so 7 copies of allvalue names exists.
But this way, its hard to get a good over view of the data.
The default/“OK” value is “0000” and im tryhing to catch the fault code of the modbus communication with 7 pressure sensors on my desk, but randomly i get some error on a random device.
If that’s a power table, I would look into the configureCell extension function.
If the cell’s contents are 0000, I would consider not displaying anything - but for any other value, you could give the particular cell a vibrant background color to immediately grab attention.
if is. and i got some script that semi-works
if (textValue == "0000" and Value < 99999 and value > 0 and trim(textValue) <> ""):
return {'background': 'white', 'foreground': 'black'}
else:
return {'background': 'purple', 'foreground': 'white'}
But this still marks “empty” cells, and date/time cells (t_stamp), cant really figure out whats really wrong, but the if-statement seems a bit over kill for this.
Also, how can i sort this on the column t_stamp so i get the newest first?
Now its displayed as entered in the tag historian database (=oldest first)
Yesterday i changed it up and made 7 power tables.
Still not so much viewable, and this is just after a trial end and just started up the hmi, cpu spikes and so far only one of 7 shows any data
And some wierd thing happened.
The mysql database contains 23997 rows of tag data.
Bith the designer and vision client now is suuuuuuuuper slow and consume alot of cpu.
Saving the project can take 30 minutes (tried rebooting several times)
Did you check the 'Retain Rows' checkbox on the binding that populates the data on this table?
Does your script still look just like what you originally posted, or have you made further changes?
Generally slow behavior means there's either something holding up the event dispatch thread (which is where configureCell has to run, so you must make sure to avoid 'slow' operations like tag reads or DB operations) or there's an extremely large dataset being saved into the Vision window (which unchecking 'Retain Rows' avoids).
Nope, never checked that box.
The sql is different now:
SELECT sqlt_data_1_2021_11.t_stamp, sqlt_data_1_2021_11.stringvalue, sensor.tagText AS SensorText, ecodes.errortext FROM sqlt_data_1_2021_11
inner join sensorid Sensor ON sensor.tagID = sqlt_data_1_2021_11.tagid
inner join ecodes ON sqlt_data_1_2021_11.stringvalue = ecodes.errorcode
WHERE stringvalue != "0000"
;
This filters out 99.99999% of the data since most records are “0000” and only leaves me with errorcodes, that the joins translates to a sensor and errorcode with text from the help file matching the ID’s
EDIT: Now i got to find a way to convert the t_stamp to actual date/time, the from_timestamp in mysql doesnt work for example.
Curious what your plan is when we rollover into December. If you are using tag history, then to me it's easier to get the data via script,
https://docs.inductiveautomation.com/display/DOC81/system.tag.queryTagHistory
For t_stamp, see this post,
FROM_UNIXTIME(t_stamp/ 1000)
Its not for production, its only to look for problems on my desk plc, so i caneasilly just change with table i want to look at for the day, trying to find a reason behind the random modbus time outs im getting, and thought to use the tag history in educational purpose.
You can’t use the PLC for traps?