What do you mean by this? Concatenate both dateTimes into one string, write it to a parameter, and then use SQL to break them apart somehow?
1 Like
Yes, as many parameters as you want to reduce to one.
I usually allow my queries to run when a filter is changed and try to get my queries to under 300ms.
1 Like
I wouldn't, strings are slow, and you can loose information that you otherwise wouldn't.
If you have them as dateTimes, leave them that way. Any string conversion or formatting should be the last thing you do.
1 Like
Multiplexing would satisfy the one update requirement.
Multiplexing can be done in smart ways without strings too.
A query is faster when you don't multiplex.
1 Like
I FIGURED IT OUT!! I finally figured out why the timeline wasn't rendering correctly! Or rather I figured out when it doesn't render correctly.
In short, if you have a series object named 'Down', but you don't have a dataset named 'Down' in your dataSources, it will fail to render. If you change any prop (e.g. enable/disable the legend), the chart will render. It's a strange bug.
So my timeline displays the status of production - we were either running, slow, or down. I set my Start Time and End Time to view a few hours where we never went down (surprising rare around here 
), so the Down dataset was empty, but it still existed. For some reason, instead of showing no Down data on the timeline, it actually shows Down whenever the status is supposed to be Running (@cmallonee, as Quality Control, you may want to look at this). If you disable Down visibility by clicking it in the legend, you actually see the Running status beneath the Down parts. This is an even stranger bug. To get rid of the bug, I removed the Down dataset from the dataSources, and the render problem returned 
...
I'll guess I'll have to programmatically build the series prop to account for this? It kind of sucks considering there's a lot of properties in each series object. That or add bogus data to the Down dataset.
Here's a few screen recordings of the bugs I talked about previously.
Here, the Down dataset is rendered on top of the Running dataset. You'll see I delete the Down dataset (you can't see the right-click menu in the screen record because it only recorded the Ignition window), and the timeline displays correctly. I then bring the Down dataset back, and disable its visibility to show the Running data beneath it.
Here, the series visibility doesn't work how I expect it to, but maybe I'm understanding it wrong. I would like to disable visibility when a dataSource dataset is empty, so that it doesn't render on top of valid data.
Here is a link to an earlier post I made showing the issue where the chart decides not to render until some property forces a re-render.
1 Like
Why do you bind datasources, instead of a datasource?
I'm the author of the Ribbon Chart resource.
Yup, it's a weird issue if you don't recognize what's happening. The exchange resource handles this by creating a fake entry for every series if no real data exists.
3 Likes
I originally had 3 Name Query bindings to populate the 3 datasets, so I was binding to a datasource instead of dataSources. To increase performance, I used one query to return all the data in one dataset, and then I used Python list comprehensions to break them into 3 datasets. It was faster to use a script to break them apart than it was to run the query 3 times. Here's a little snippet of my code:
running_data = [item for item in data if item[pace_index] == "Running"]
down_data = [item for item in data if item[pace_index] == "Down"]
slow_data = [item for item in data if item[pace_index] == "Slow"]
This is another instance where I wish queries could return multiple datasets. Something like this would be great:
Running, Slow, Down = system.db.runNamedQuery('DownSlowRun_Timeline3.0', params)
1 Like
Holy crap, I actually remember seeing that when reading through all the code to get a general idea of how your ribbon chart worked. I googled AMChart and quickly realized what you were talking about was well above my head, so I moved on.
Nice work on the chart by the way!
1 Like
Then my question becomes, why do you use three data sources when they are in one data source?
Is that a requirement of the ribbon chart?
It allows me to have different tooltips for each series. For example, when a machine is down, you can hover over the down event and see the reason. We're not collecting reasons now but will be in the very near future. I don't need to display a reason for why we're running.
Technically, it's not a requirement of the Gantt Chart according to the manual's example. But there's not an actual instruction on how to use it. There's just an example of how it can be used.
1 Like
Yes, having each category in its own dataSource is the easiest way. The Ribbon Chart resource tries to hide this behind the scenes by providing a single "data" parameter so the user doesn't have to worry about keeping dataSources and series in sync.
You absolutely can create a Gannt chart with a single series/dataSource, but you have to manually provide your derived color fields and you lose the ability to toggle individual states on and off.
The XY Chart is a great tool, you just have to be sufficiently motivated to struggle through it.
1 Like
Questions about series:
You are saying there is a series for each of the individual states?
In the example here, it is only possible to toggle slow, running, and down.
I thought this meant that those were the series.
Tooltip
To get the tooltip to show the state at a time, it is about how you configure the tooltip to read?
You can make it get the reason column based on the time and series that is being hovered from the source?
My tooltip is usually: {name}: [bold]{valueY}[/]
Learning these techniques
The fastest way for me to learn what is going on is to go to the exchange for the ribbon?
Or is it hard to figure out from that?
Questions
Yes, there is a dataset for each individual state. Here's a screenshot for clarification:
I'm not quite sure what you're asking here, but I think you're only able to toggle states on and off if they're tied to a series. And I'm pretty sure you can only have one series per dataSource data source. @bmusson, who seems to be familiar with the AMChart that this Ignition component is based on seems to agree.
Tooltip
My Down and Running/Slow tooltips are different. The Down tooltip has a "reason" to show why the machine went down. I don't think it's possible to have different tooltips for different statuses without having multiple series. You might be able to script it somehow, but I don't think so.
Here's my tool tip for my Down series:
[bold]{name}:[/]
[bold]Reason:[/][light] {reason}[/]
[light]{start.formatDate('EEEE M/d, hh:mm a')}[/] [bold]to[/] [light]{end.formatDate('EEEE M/d, hh:mm a')}[/]
Here's my tooltip for my Running and Slow series:
[bold]{name}:[/]
[light]{start.formatDate('EEEE M/d, hh:mm a')}[/] [bold]to[/] [light]{end.formatDate('EEEE M/d, hh:mm a')}[/]
Learning
I have learned a lot from the Inductive University, the manual, the forums, and I've tried to learn from projects by others like Ignition's default sample project and @bmusson's ribbon chart. Learning from more experienced players by examining the work can be helpful. For example, I now know how to use multiple series and dataSources the Gantt functionality of the XY Chart.
1 Like
In my XY Charts, I set the series according to the columns I want to view.
The Gant chart seems similar to a horizontal stacked bar graph.
Data sources
It looks possible to use one data source or separate data sources
It looks like either source technique can fill the 0s from the query or scripts.
Query speed
Your current technique seems to have minimized data in the query.
I think a single source query with zeros inside it would be the fastest.
I don't see data source specifics, but I learned most the stacked bar chart here:
Stacked Bar Chart Detailed Steps
It looks like the url is missing from this link.
1 Like