Using Ignition 8.1.7, in Perspective. I’m using an XY chart with a dataset bound to a named query that refreshes every 10 seconds. After a couple of refreshes, my chart looks wonky:
Any suggestions?
Did you ever figure this out?
I'm having a simlar issue. I have the data bound to a named query that runs when I select a row from a table. It then runs a script transform to alter the data a bit.
Sometimes it just keeps the data from the last one I had selected (but not all of the data oddly). I assume the same is happening to you. If I check the dataset, it looks like it should (only 1 set of data), but clearly the last set of data is appened to the end in the rendering.
I think I figured it out, but it isn't pretty.
Since it had to do with the rendering because binding read something different I tried removing the binding on the chart completely. I started setting the property based on a script. Here's what I did:
-
Remade the binding on the component that selects this (a table). In a custom property of course.
-
Then, I put an on change event script on that property. It cleans up the data as needed.
-
Finally, that script sets the chart's dataset to the new one. So, this avoids a binding on the chart.
I haven't seen the issue since I did that. If someone finds a more efficient solution, I'm all ears.
If you bind the data on the chart component, and then use a script transform inside of that, does it work?
On one of my charts, I have the named query, but then I use a script transform to return value or to return an iteration through the query depending on which one.
I thought maybe this additional processing would "fix" it.
I am on 8.1.19.
I also only have the data going to the binding that I use in the chart, and then I set opacity 0 on any series I don't want to show. I am working on making some of my series dynamic, but I am so far trying to do that on the SQL side via parameters.
That's what I did at first in 8.1.25, but without success.
The named query was bound to the data property with a script transform to alter the data (just appending a value at the end). It would work ~70% of the time and the rest would make it look strange.
How many series do you have on the chart? The odd thing with my issue was that 2 out of the 3 lines from the previous selection would stay consistantly (when the error occured). That last one (green) would only show for the correct set of data.
When mine was erroring, I had been sending 20 columns and trying to use 5 series.
I got help from IA, we used a script to narrow down to 1 X series and 4 Y series.
The X series was in the first column.
I had to filter duplicate X values and fill in null/zeroes from my script.
Was kind of hard. I didn't seem to have the issue after that.
Now I filter duplicate X values and fill in null/zeroes all in my query.
I have not had the issue since I did this.
I also did a bunch of work to eliminate duplicates on the gathering side of my data.
I am working on dynamic series still. I have things to try for that yet.
I did add a final column recently that had actually datetimes so I could tooltip the day of the week.
My x series is sorted on a string.
Might be much faster if I go back and make that a datetime now.
Hmm that seems very similar to my process. 1 dataset, multiple columns/series, and the X value in the first column.
I'm having this issue on a different XY chart now 
. It is completely different and has multiple datasets with named query bindings (no script transforms) and multiple series. It's frustrating because that had been working consistantly for 3 weeks and now I'm having issues. I think the only thing I changed was the title property this week.
Maybe it's time to give IA a call.
I use one binding to one query.
If I have to join things, I do it in the query.
But I think there is a post about a gant chart made from an XY chart that shows technique for multiple bindings.
This is the strangest bug that I've encountered in a long time. Maybe someone brighter than myself can make sense of this shenanigan:
For context, this chart is actually an embedded view and running in a tab container.
- I tried the method of just hard scripting the values. No deal.
- I thought back to the one change that I made before it broke: a binding to the title.
- When it was removed, it worked perfectly. Strange.
- I tested a variety of things: the binding on but removed others, more bindings, different binding, that binding on a different properties.
- It was an issue that specific binding which was just bound to a custom session property. I tried with a different custom session property, and it worked fine.
- The troublesome session property is from a lookup value (based on when another session value changes)
- I then made that session property a parameter of the embedded view. That worked.
- I then began questioning why it was an embedded view in the first place. So, I redid the chart not as an embedded view and using bindings from the session directly not the embedded view parameters. This included that troublesome session property. It works perfectly (today).
Hopefully, that was a enough detail, but TL;DR: a session property was causing the error in my embedded view, so I made it not an embedded view. Alternatively, I could have just made the session property a parameter of the embedded view.
Is this related to some other known bug in embedded views or session properties?
I have a similar problem on my XY chart. I just have 3 tags configured for tag history with property bound start and end dates. It seems like when I open the view sometimes it is stuck with weird data and makes the chart look like it has double data or like the first point and last point are connecting... Usually fixes with time or a refresh.
I had the error today when I had bound my Y axes range max to an expression binding.
I don't know how embed impacts it, but I think it is tied to the property binding timing.
v8.19
I got rid of the issue by binding my Y axes to a query, same as my data query, then using a transform to get the value I wanted from that.
I think the binding timing sounds more likely than the embedded view or a session property.
Your scenario has similar factors to mine. Unfortunately, I'm not sure what the smoking gun solution is. If I can't fix this the next time, I could try putting property change print scripts to determine the order in which the bindings change. If it lines up consistently, that could clear some things up.
Phil had posted on another issue I was having that using an expression structure might work to get the values at the same time, but I did not figure out how to get an expression structure to work before I just used two queries.
Can you link to that post?
I tried putting a binding on the axes, but no luck. If anything, it's happening more.
I have a ticket in with the support team, but their having trouble replicating the issue at the moment.
Here is the link, but I didn't figure it out.
I am running the same query for values I check, and then I have a script transform that looks at those to spit-out the values I want for the different bindings.
Here is a way to check on types in python --- return from a dataset was easy
return [type(columnName[index]]
return [type(hours[1]), type(net[1])]
Or maybe push your data to a table, maybe your data has duplicates or type ordering obstacles?
Or hidden milliseconds when using the datetimes?
These were some gotchas that got me and took a bit anyway.
I didn't remember how I had written the script for filling in zeroes.
So I wanted to append a note here on a query that will let me fill in zeroes from a query.
WITH SampleData AS (
-- Your original query to get some amount of rows
SELECT TOP 10 Column1, Column2
FROM YourTable
WHERE YourCondition
ORDER BY SomeColumn
),
ZeroFilledRows AS (
SELECT TOP (10 - (SELECT COUNT(*) FROM SampleData)) 0 AS Column1, 0 AS Column2
FROM SampleData
)
SELECT Column1, Column2
FROM SampleData
UNION ALL
SELECT Column1, Column2
FROM ZeroFilledRows;