| Author |
 Topic  |
|
|
javaman
22 Posts |
 Posted - 08 Jul 2009 : 14:36:55
|
Sorry to start another thread - but it appears that sometimes when you update a thread, no responses occur. I wanted to ensure I get a fresh set of eyes.
Okay - it's still happening - autoScale method for a TimeCoordinates object is still getting stuck ( it either just hangs for about a minute - or it goes into an infinite loop ). What I've discovered is that it doesn't like the difference in the plot points to be less than a sec apart - when I modify the data to meet that requirement (be a second apart) - it works fine. BUT, my data can come as fast as 1 msec apart. We've traced it to the updating of the XAxis as the culprit - if you'd like to see a thread dump - let me know.
I seriously need your company's help on this...
Oh, the values on the YAxis has no impact on the autoScale...
many thanx...
Thanx - Joe! |
|
|
quinncurtis
1164 Posts |
Posted - 08 Jul 2009 : 15:55:05
|
A thread dump won't tell us anything, we need a simple example program that reproduces the problem. So find a range of time values that reproduce the problem 100% of the time and hard code a graph that demonstrates the problem.
The auto-time axis routines have a minimum range of about 20 msecs. Is the time range you are trying to auto-scale on smaller than that?
|
 |
|
|
javaman
22 Posts |
Posted - 08 Jul 2009 : 16:50:52
|
Yes - it's smaller than that - it could come in as much as 1000 points a second... So, you're saying that the data has to be spaced at least 20 msec apart?
please confirm.
Thanx - Joe! |
|
|
|
quinncurtis
1164 Posts |
Posted - 08 Jul 2009 : 17:02:38
|
No, only the the minimum time axis range is 20 msecs. If you have 8 data points and they are 1 msecs apart, that is a problem. If you have 20 data points and they are 1 msec apart, that corresponds to at least a 20 msec range and that is OK. Sor either wait until you have enough data points to fill a 20 msec range, or force your minimum time axis range to be 20 msecs using code simliar to below.
pTransform1.autoScale(Dataset1, ChartConstants.AUTOAXES_FAR, ChartConstants.AUTOAXES_FAR );
if ((pTransform1.getScaleStopX() - pTransform1.getScaleStartX()) < 20)
pTransform1.setScaleStopX(pTransform1.getScaleStartX() + 20 );
|
|
|
|
javaman
22 Posts |
Posted - 14 Jul 2009 : 17:09:58
|
Okay - a couple of points on your code:
The problem is with autoScale - setting that values after you do autoScale doesn't relieve the problem. It's too late by then.
Did you mean to do that setting before you autoScale?
Next, I have a nit to pick: How was I to know about the 20msec problem? It wasn't in your docs (I checked). So, in effect, I wasted several days time trying to figure out what the problem was - time that I lost trying to get our product out the door for shipment.
Finally - you say that a new version is to come out soon - does this include a fix for this 20msec limitation?
The solution you offer is not good - you are in effect modifying the timestamps of the data (by extending them by 20msec) - this is not acceptable - we cannot change the data - it gives a false sense that the data is valid and in range for your tool - but throws off what we're trying to display.
Thanx - Joe! |
|
|
|
quinncurtis
1164 Posts |
Posted - 15 Jul 2009 : 00:27:56
|
We tested it and the autoscale of the coordinate system with a 5 msec data range worked for us. The code that we showed was copied directly from the example program we used to test it. It is the auto-selection of the axis that fails. The smallest time axis we have coded uses a 20 msec range. That is why after the autoscale of the coordinate system, we forced it to a 20 msec range, so that it could use the 20 msec time axis. Are you saying that it fails the coordinate system autoscale for you? If so, can you supply with a set of data (x,y) values that reproduces the problem?
Below is a picture with data that had a 5 msec range plotted using a 20 msec coordinate system and axis.
In this example, the data is plotted at the proper locations on the x-axis.
The software has a granularity of 1 msec for all time/date data, because that is the underlying granularity of the Java GregorianCalendar class we used for time/date values. We can't change that. Given that constraint, a minimum time range of 20 msecs for the x-axis seems reasonable. That allows the plotting of 20 discreet time values. Less than that will still be plotted correctly, it just won't fill the 20 msec range.
We have always been aware of the 20 msec range limitation. We don't even list msec time axis ranges in the manual. In the description of valid ranges for the TimeAxis, the manual stops at an axis which uses a 1 second tick interval, which is much larger than we actually support. As far as we know, no one has every tried to auto-scale and auto-select an axis as small as you are using, using GregorianCalendar time values.
Nothing we have suggested causes the time stamps to be modified in any way. The data is always plotted exactly where it should be in relation to the x-axis. We don't understand what you are trying to describe. If you can provide some sort of simple example (a complete program) we will look at it.
We weren't planning on making any changes in this area. What we can do is add a new axis range that has a 5 msec range with one tick mark per msec. Anything less than that, with a granualarity of 1 msec, doesn't make any sense. In the 5 msec case you will only have 5 descreet time slots you can plot the data on. |
|
|
| |
Topic |
|
|
|
TimeCoordinates autoScale problem (again)...
