Has anyone seen this? my graphic was rotating correctly and then suddenly starts changing sizes.
I'm guessing it's floating point round-off error, like in this other post about animation issues.
Maybe this post's suggestion could be useful?
Can you add the Perspective or Vision tag to your question? It looks like Vision to me.
I don't see any values being accumulated here so it's probably not that.
Where does that tag get used for the animation? Maybe that can shed more light on the issue.
It is supposed to count the minutes elapsed in a heating cycle, show the current time setpoint and count the minutes passed the current heating cycle that the material has remained in oven.
The tags from the Expression: TimeRemaining.value is the time left in the cycle from the PLC. CureTImeSP.value is the the setpoint value for the current cycle. BarIntervalBase.value is the initial interval over setpoint that counts in the PLC up to a certain level. If the "Base" value is exceeded, the BarIntervalAdditional.value is the time accumulated in the PLC over the Base. These are all tags originally set up in an old Indusoft HMI that I am translating into Ignition.
OK, so those are either constant or get reset often so are probably not running into float issues.
That said, could you show me where the ClockHandPos
binding is used? I'd like to see the actual set up of the animation portion itself.
The graphic for #4 above shows a base point for any oven. The vertical hand is at position zero before the timer starts. The tag information shown above is the calculation for the clock hand position that is bound to the angle value of the hand. Since I did not note a method for defining the end of the graphic for the hand as the rotation point for the angle, I actually have only half of the pointer visible so that it can rotate about the center of the graphic. As the seconds count out in the PLC, the value for the rotation should increase the angle around the clock face. You can see the orange hand is rotated to the 13 minute mark for the cycle time setpoint.
I wonder if that workaround has anything to do with it.
You should be able to change the center of rotation by clicking and dragging the red crosshair that appears when manually rotating the shape.
Does the rotation break things for the smaller orange hand too or just for the large hand?
The smaller orange hand is designed the same way, but that value is based on only one setpoint value and does not change during the cycle. I did not notice the crosshair before. I will look at that.
I don't know if this adds any more information, but I have two different displays for the same component in designer and runtime.
I did try modifying the clock hand to take advantage of my new knowledge to be able move the center point.
Is there any way you could export and upload some sanitized version of this thing? I believe it would increase our chances of solving the problem.
This doesnt really look like it just got bigger, the base is twisted too (the angles are no longer the same)
TimerTemplate.zip (48.4 KB)
This uses a property called PoolNumber for indirect tag addressing to determine which area it represents. The "hands" have tag binding on the angle property. My tag is simply a count up of the minutes elapsed in the process. The orange hand shows the time setpoint in the same way. The top right number shows the PoolNumber above. The numeric in the rectangle shows a variable of time remaining, the opposite of my minutes elapsed.
I tried a different approach on the hand. I thought perhaps that Ignition's handling of the rotation couldn't deal with the polygon (triangle) I was using. I tried using just a line for the hand:
And then this just started:
seems you are not rotation around the center
I did a preliminary setup in my test environment, and so far, the hand has behaved correctly. For anybody that wants to take a crack at this, this is Vision, and here are the float tags that are needed for the template to run:
tags.json (474 Bytes)
Using these tags, the poolNumber parameter will need to be set to 1
@steven.rehnborg About how long does it normally take for the anomaly to occur, and does the problem happen in the designer, or does it have to be in a session?
It happens in designer and on my client. Sometimes everything will be operating normal and others times everything is messed up.
Right now I have 2 out of 12 displaying correctly.
I remember reading about a similar problem not too long ago that was determined to be a consequence of floating point calculation errors: Fan Rotation Animation Problem
Perhaps you could try casting the values to integers and using integer tags instead?