JSON level 5 responses are hard to check for correctness

Home › Forums › TinyG › TinyG Feature Requests › JSON level 5 responses are hard to check for correctness

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • October 31, 2014 at 11:23 am #6955
    moeter
    Member

    In JSON mode, responses are not quite as I would assume responses should work. They don’t return the line you just sent in the “r:” part, but sometimes a somehow parsed version, with added precision. Let me give you an example:

    If you send {“1tr”:45}, then the response given is {“r”:{“1tr”:45.0000},”f”:[1,0,11,7676]}, which is, in a way correct. But it makes parsing the answer a major PITA.

    Could you fix the responses, so they return EXACTLY what you actually sent, or, second best, give a list of default precisions of these values?

    Thanks.

    October 31, 2014 at 11:51 am #6956
    cmcgrath5035
    Moderator

    Issues like this, which may/ay not be release specific, are better reported on GitHub; makes tracking much more efficient for the developers.

    Assuming you are referring to FW438.02, which is still DEV, that would be here:

    November 2, 2014 at 2:36 pm #6963
    alden
    Member

    How are you parsing? Most UI’s using JSON are using the native JSON capabilities in JavaScript, Python or whatever. Floats are floats, so it doesn’t matter.

    There is a list of precisions in the config_app.c file. The table sets what precision the results are returned. There may be a few special cases where the answer may be different in mm mode or inches.

    November 3, 2014 at 3:41 am #6964
    moeter
    Member

    Actually I’m not using a “real” JSON parser, because for security reasons I am not allowed to. I am building embedded software, that is controlling TinyG for using it as a more generic robot controlling system.

    It’s kinda okay what it returns, and the list of precisions is helpful. But I still reckon it suboptimal, as these responses are the only way to actually check for comm errors, and identical strings would make this more straightforward and faster.

    And actually I’m using an EDGE build (435.10) where I fixed this issue myself…

  • Author
    Posts
Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.