HTTPCMD Responses

[JeffS]

So I have been using the HTTPCMD to communicate with a server and this is a typical successful response returned by the command:

{"succeeded":true,"redirectURL":null,"message":"96 rows added
","requestedData":null,"errorCode":0,"errorCodeDescription":null}

Occasionally though I get strange responses like:

84..{"succeeded":true,"redirectURL":null,"message":"96 rows added
","requestedData":null,"errorCode":0,"errorCodeDescription":n

So it appears it is returning the JSON package offset by 4 bytes as the last 4 have been trimmed and leading 4 are not part of the JSON response and this results in a HTTPCMD error.  But it was a successful transaction other than the strange offset.  This triggers my code to send it again which gives me duplicates in the server. 

[franji1]

Are you using a string or a buffer?

[JeffS]

If I clear the Response String before calling the HTTPCMD then instead of the added 84.. to the front and truncated last 4 characters, I get an empty string.

I am using a buffer.  Attached is a pic of the rung in my code.

[franji1]

I would recommend not using an IF/ELSE construct on two different edge instructions.  If the IF condition "twitches" in the middle of that stage execution, you definitely will see very strange behavior.

Try branching to 2 different stages based on the condition of your IF/ELSE construct:

STRN C4801
JMP S40
NOT
JMP S41

then put the 2 different HTTPCMDs in their OWN stage.  That will eliminate any strange behavior with a twitchy C4801.

This is a common SFC "branch" construct, basically, a step (stage) forks the behavior down 1 of 2 (or 1 of N) disjoint paths (see JMPI for how to do this in a single instruction instead of multiple JMPs).

If C4801 is set using PD coil, or by an OUT coil in a Stage being JMPed out of, you will see strange behavior.  Or it could be that the bit is just being cleared based on some independent logic that has a state lifetime shorter than the lifetime of these HTTPCMD instructions.

When you hit this forking stage described above, you are leaving it immediately, so the driving bit can "twitch" all it wants because the divergent path has already been chosen.

[JeffS]

The If else construct is there just for testing and doesn?t toggle unless set on manually, so in this case it never twitches as it is not controlled by anything in the program.  Unless you think the fact that it exists at all is causing issues, in which case I?ll make the changes recommended.

[franji1]

The If else construct is there just for testing and doesn?t toggle unless set on manually, so in this case it never twitches as it is not controlled by anything in the program.  Unless you think the fact that it exists at all is causing issues, in which case I?ll make the changes recommended.

IF/ELSE and 2 EDGE triggered instructions that share the same buffers is a red flag.  It may be fine, but it is potentially a huge problem if you happen to set or reset that bit (or something else is setting or resetting that bit) in that "window".  I'd rather eliminate the "window" rather than assume it works perfectly.

I'm not saying this is the issue, I'm just eliminating 10,000ft. "red flags" since I don't know (or need to know) the details at "ground level".

Also, JMP to different stages On Success vs. On Error so you can know if that's the difference.

[JeffS]

OK, so I just removed that bit of code so the stage is just the one HTTPCMD with no branching.  Initially I had the HTTPCMD jumping to two different stages based on success failure, and changed it to jump to the same stage when I thought I was getting an error but some kind of legit response I could parse.  Now that I am getting an empty string I could have it jump to a different stage like before.

After this change I am still getting pretty regular HTTP failures.  Out of the past 143 attempts I have had 29 failures, which means 29 duplicates as they are actually making it to the server.

[franji1]

OK, so I just removed that bit of code so the stage is just the one HTTPCMD with no branching.  Initially I had the HTTPCMD jumping to two different stages based on success failure, and changed it to jump to the same stage when I thought I was getting an error but some kind of legit response I could parse.  Now that I am getting an empty string I could have it jump to a different stage like before.

After this change I am still getting pretty regular HTTP failures.  Out of the past 143 attempts I have had 29 failures, which means 29 duplicates as they are actually making it to the server.

When using buffers, the status can get strange especially if you are re-using buffers, or on failure (e.g. if it fails, and does not get a valid response, does it still update the response length?  I'm guessing NO, hence the buffer STATUS will be WRONG when it fails, based on previous or other uses of that buffer).

[JeffS]

Actually, I am sending data from a buffer but the response is a string.  It is a Custom made string to be 1024 characters, but a string.

[JeffS]

Since I made these changes I decided to try not clearing the string before the HTTPCMD and see if I still get the odd Response string contents. 

When the HTTPCMD is going to fail the contents still gain the 84.. in front of the response and the last 4 are still truncated.  I say going to fail because as soon as the stage comes on this string updates but the jump to my error stage doesn't occur until the timeout. 

So far every one of these have successfully put information in the server so I doubt it is a connection issue.

[BobO]

You are running the latest firmware, right?

[JeffS]

This at customer location and is currently running 2.7.3 firmware.  I will see if I can get it updated and if that changes this behavior.

[BobO]

This at customer location and is currently running 2.7.3 firmware.  I will see if I can get it updated and if that changes this behavior.

There was a fix in chunked HTTP payloads in 2.7.4 that could have caused these issues.

[JeffS]

OK, that firmware update appears to have fixed this issue.

[BobO]

OK, that firmware update appears to have fixed this issue.

Sorry we didn't get you to that resolution sooner.