Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000456TunixGeneral Featurespublic2011-12-02 10:022011-12-02 21:49
ReporterFred 
Assigned ToFred 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformAllOSAllOS VersionAll
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version0.9.24 
Summary0000456: Erroneous RAM Writes Sent When Moving Through Cells
DescriptionIn the 2D view of the 3D tables, the first time, and ONLY the first time, that you move into a cell, either by mouse, or by up/down arrow (why don't left/right do the same thing and navigate?) it sends a write packet (I presume) to the device with no change having occurred. Subsequent times through it doesn't do this so I presume that the RAM cache of the ECU RAM is not initialised correctly or at all such that the cell value displayed varies from what backs it until you click in. Yes, that's almost certainly what is happening because it doesn't happen in cells that are zero to start with.
Steps To ReproduceThis is easily visible by disabling streaming with an adapter with LEDs on it and doing what I described above.
TagsNo tags attached.
FirmwareVersion
Attached Files

- Relationships

-  Notes
(0000835)
dandruczyk (viewer)
2011-12-02 13:21

noted.
(0000852)
dandruczyk (viewer)
2011-12-02 18:46

Fixed with hash 7b3830ade81fc14c068071cc98239093ea8bef9c
(0000853)
dandruczyk (viewer)
2011-12-02 18:47

Fixed in: 7b3830ade81fc14c068071cc98239093ea8bef9c
User avatar (0000854)
Fred (administrator)
2011-12-02 18:57

Tested, works properly now. Only the rounding thing which you previously explained still happens and that's acceptable, though solvable, if you cared enough :-)

You could store what the display value was and compare for a change with that, then only if that is different propagate it further, but I don't care, and I doubt you do either :-)
(0000859)
dandruczyk (viewer)
2011-12-02 19:28

RE the rounding , no, not in every case. In some instnaces the conversion expression results in a string that won't match exactly when the precision is taken into account in the gui..
case in point

Raw value 1.2345
Value seen in gui, 1.23

Values DON'T match when comparing even though the gui precision in combination with the conversion results in a mismatch.. This is more of an issue on MS, where they use 8 bit values with odd conversions which result in floating point values with lots of digits...

ITs good enough the way it is, so no furhter action will be taken.
(0000860)
dandruczyk (viewer)
2011-12-02 19:29

Added note, no need to respond
User avatar (0000863)
Fred (administrator)
2011-12-02 19:35

You could write into the gui, read back out, and store it separately, though I agree, good enough. Why you opened it and closed it again, I'm not sure. Perhaps you couldn't comment on it while closed? If not I might adjust the settings a bit.
(0000864)
dandruczyk (viewer)
2011-12-02 19:36

Can't comment when closed, hence the reopen, comment, close three-step
User avatar (0000865)
Fred (administrator)
2011-12-02 19:48

Should be able to now.
(0000866)
dandruczyk (viewer)
2011-12-02 19:50

Much better, thanks
User avatar (0000880)
Fred (administrator)
2011-12-02 21:49

Now if you go into a cell, don't change it, and hit enter, it sends a packet, but if you hit enter again it doesn't. Ignore if you don't care, it's unnoticeable to your average user.


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker