FreeEMS Issues - Tunix
View Issue Details
0000428TunixGeneral Featurespublic2011-11-26 14:212011-12-02 09:42
0000428: Tunix Allows Invalid Axis To Be Sent And Continues To Display Invalid Values Despite Error Not Updating On "Get Data"
I tried to send a bad axis configuration and got this in the console.

Don't know how to handle this type..
Packet ERROR Code 0x6005, "Invalid main table Load order!"

Given that it states that you don't know, I'm going to tell you here :-)

You should revert the change, or let the user know that they did something wrong in an obvious way and that it's NOT in the firmware. Right now it looks like it is in the firmware when it's not. The firmware rejected the change that would have broken its ability to do its job. Try it. I changed 62 to 53 creating an out of order axis and it looks like it stuck, but didn't. Worse, when you do a get data it doesn't update this. Even if I change tabs and back again. The other way you can handle this is with sanity checking in the UI not allowing out of order values to be sent to the controller. Maybe an axis editor which lets you change them all at once and send afterward would be best. Your call.
I put it under general features as you probably shouldn't send dodgy axis to other systems either, even if they accept them blindly.
No tags attached.

2011-11-28 01:50   
Not doing order checking in the UI, it puts too much intelligence in the WRONG PLACE and creates more "one-offs" that are buggy error prone and difficult to maintain over the long term.

Will work on a rollback scenario. HOWEVER. when submitting an axis value that is out of order for the series, and receiving the error and then setting it back the datalog stream is completely corrupted and screwed, and it takes either a soft or hard reset to restore order. So you may wish to check the firmware to see that it isn't going off into a bad state.
2011-11-28 11:22   
The error checking doesn't have to be IN the UI, but it definitely needs to communicate feedback to the user that they screwed up through the UI from wherever it's done. This is what exceptions in Java are beautiful for. Just throw one at some low level and let it bubble up to somewhere where it can be dealt with appropriately, in this case, the gui component that the user is interacting with.

I've fixed the issue that you saw, please pull from my dev branch and test and if good close 0000440 :-)
2011-11-28 11:23   
Why did you assign this issue to me? :-/ Assigning back. The thing you found was unrelated to this issue...
2011-11-28 23:06   
Fixed, gui properly rolls back to previous value.
2011-11-29 12:39   
Marking resolved for you, again.
2011-11-29 13:50   
FFS Dave, I test your fixes and close, you test mine and close. You fix and resolve/assign, I fix and resolve/assign. Got it? Good.
2011-11-29 13:50   
2011-12-01 16:18   
Why did you do that? I tested this and it didn't appear to work. I will do further tests and ***I*** will reopen or close at will. Stop closing your own issues.
2011-12-01 16:28   
You told me to close it ABOVE^^^^. Stop assigning shit to me if I'm not supposed to close it.

IF you didn't do a full pull/make/make install it won't work, that should have been obvious by now.
2011-12-01 16:45   
I most CERTAINLY DID NOT. You failed to mark it resolved when you assigned it to me. I did that for you. Then you closed it when you should have left it alone. I then opened it and complained and explained and set it as resolved. You then closed it again. So I complained and opened it again. Now you've marked it assigned and I have to fix it again. FUCKING LEAVE IT ALONE, it's MINE to test and deal with. I don't have time for these games. You getting an email does NOT mean that you have to take action on something...
2011-12-01 17:10   
Then you might want to explain the flow better than just that forum post, cause evidently it didn't sink in as to which way makes sense. Each time I get an email I am expected that I need to respond in some fashion or another. the email never makes that clear
2011-12-02 09:42   
Closing, confirmed this behaviour works correctly in 110d7672d85c00b660efa2f4b3eb8a31e699c8d9, well done Dave! :-)