News:

  • September 19, 2019, 07:03:57 AM

Login with username, password and session length

Author Topic: SS memory and pointers  (Read 15617 times)

plcnut

  • Hero Member
  • *****
  • Posts: 801
    • premiersi.com
Re: SS memory and pointers
« Reply #30 on: October 17, 2012, 10:25:53 AM »
The equal sign entry is a known bug.

You have to be online to the PLC to see the ASCII status, and turn status ON for the Data view.  Click on the Data View, then click on the Status sticky button to enable status for the current view (2nd toolbar from the top).

Thanks franji1,
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

plcnut

  • Hero Member
  • *****
  • Posts: 801
    • premiersi.com
Re: SS memory and pointers
« Reply #31 on: October 17, 2012, 10:32:41 AM »
I have the Http GET working! ;D Thank you very much Bobo for the code. Because the server I am querying is set up just for this app, I was able to get rid of most of your coding (headers, and file length). Its a load off my mind to have this portion of the app working!
Thanks again
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 4680
  • Yes Pinky, Do-more will control the world!
Re: SS memory and pointers
« Reply #32 on: October 17, 2012, 11:19:33 AM »
Glad it's working!

If the data payload is known and arbitrary, then you can easily define the data in such a way as to greatly simplify the reading of the content...most obviously by limiting the length and using some form of delimiter. When you suggested that you were using port 80, I assumed that the server was going to be a standard web server sourcing files generated by something else. In that context the more generalized code is required.

It's kinda moot though. Once it became apparent to me that HTTP GET/POST were not particularly difficult to code and both could be used on a much broader basis, I wanted to do the sample app as a way to prototype an instruction for the controller. I think such instructions could be very powerful additions to the Do-more instruction set and we are planning to add them for Rel 1.1.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

Bolt

  • Hero Member
  • *****
  • Posts: 146
Re: SS memory and pointers
« Reply #33 on: December 18, 2017, 11:17:08 AM »
It's kinda moot though. Once it became apparent to me that HTTP GET/POST were not particularly difficult to code and both could be used on a much broader basis, I wanted to do the sample app as a way to prototype an instruction for the controller. I think such instructions could be very powerful additions to the Do-more instruction set and we are planning to add them for Rel 1.1.

Did GET/POST get added to Do More Designer?  I can't seem to find much on it, and am struggling making this program work successfully, am getting 400 bad request.  Was wondering if there were newer instructions to work with before I continue.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 4680
  • Yes Pinky, Do-more will control the world!
Re: SS memory and pointers
« Reply #34 on: December 18, 2017, 11:38:17 AM »
Did GET/POST get added to Do More Designer?

No, sorry.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

plcnut

  • Hero Member
  • *****
  • Posts: 801
    • premiersi.com
Re: SS memory and pointers
« Reply #35 on: December 18, 2017, 03:23:20 PM »
Did GET/POST get added to Do More Designer?  I can't seem to find much on it, and am struggling making this program work successfully, am getting 400 bad request.  Was wondering if there were newer instructions to work with before I continue.
If you can post some screenshots of what you have then I may be able to give you some pointers.
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

Bolt

  • Hero Member
  • *****
  • Posts: 146
Re: SS memory and pointers
« Reply #36 on: December 18, 2017, 07:37:46 PM »
That would be great.  Here you go:

I am trying to get a weather file using an API key, in XML format

I am basically using BobO's ReadHttpFile program

I OPENTCP to client, it connects

I STREAMOUT "GET /api/.....xml HTTP/1.0$0D$0A$0D$0A'

I get 400 Bad Request Response

If I STREAMOUT with only 1 <CR><LF> at the end of the request I get a Timed out waiting for server after 10 seconds, and 10 seconds later the TCP.Connected drops





plcnut

  • Hero Member
  • *****
  • Posts: 801
    • premiersi.com
Re: SS memory and pointers
« Reply #37 on: December 18, 2017, 08:40:45 PM »
I believe you need to get rid of the HTTP/1.0 from you GET string, and you may need to add in the entire URL for your request ie: "http://myWebsiteUrl.com/api/theRestOfMyGetString$0D$0A"
Also, do you have a link to the api specs?
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

Bolt

  • Hero Member
  • *****
  • Posts: 146
Re: SS memory and pointers
« Reply #38 on: December 19, 2017, 01:19:00 PM »
Using full address (numerical or url) with no HTTP/1.0 and just one set of <CR><LF> results in time out.

In short, the only way I get a 400 bad request response is with just the filename after .com, and with HTTP/1.0$0D$0A$0D$0A, all other options have led to timeouts.

The info page is https://www.wunderground.com/weather/api/d/docs

The link to their customer forum isn't working...

Here is a screenshot of the page in a web browser

Thanks for having a look!




franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 2625
    • Host Engineering
Re: SS memory and pointers
« Reply #39 on: December 19, 2017, 01:43:43 PM »
Your string should look like the following:

GET api.wunderground.com/api/b4e16c90a27b013d/conditions/q/TN/Jonesborough.xml<CR><LF>
or
"GET api.wunderground.com/api/b4e16c90a27b013d/conditions/q/TN/Jonesborough.xml$0D$0A"
or possibly
"GET api.wunderground.com/api/b4e16c90a27b013d/conditions/q/TN/Jonesborough.xml HTTP/1.0$0D$0A"

based on their template in the info page link you provided
http://api.wunderground.com/api/Your_Key/conditions/q/CA/San_Francisco.json
or for your URL
http://api.wunderground.com/api/b4e16c90a27b013d/conditions/q/TN/Jonesborough.xml

Not sure if you need to insert
" HTTP/1.0" or " HTTP/1.1"
before the CR/LF

Can you get a screen shot of your entire string in a WIDE Data view using QUOTED format? (dock it on the bottom instead of the left side), or possibly use 4 Hex/ASCII format on a TALL Data View docked on the left?

plcnut

  • Hero Member
  • *****
  • Posts: 801
    • premiersi.com
Re: SS memory and pointers
« Reply #40 on: December 19, 2017, 02:14:01 PM »
Here is a working example.
I just used BobO's sample and added a little bit of code.
You can see that you will need to use multiple STREAMIN's to get all the data back. I did not have time to fiddle around with parsing the data, or even checking to see if it is all making it in, but I think I have enough here to get you going in the right direction.
(Don't forget to add in your key code to the URL).
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

Bolt

  • Hero Member
  • *****
  • Posts: 146
Re: SS memory and pointers
« Reply #41 on: December 19, 2017, 09:26:50 PM »
Many thanks to plcnut for helping me out here.  I briefly tried franj1's suggestions, but quickly moved on. I was able to take plcnut's example program and make it work in my simulator.  It's a little messy, but proof of concept has been achieved.

I wouldn't mind a few tips on cleaning up my program.

I STREAMIN the api's data into SXL0-3.  1024 bytes each, SXL3 only 256.

I STRFIND each SXL string, searching for, in this example, "<temp_f>", and if found, do a STRSUB with the remainder of the string after the found <temp_f>

I do a STRFIND on the newly created string, and find "</temp_f>", and STRSUB the rest out to a SS.

I STR2REAL this SS to an R value, and have my result.


Questions,

Am I going about this the right way, or the long way?  I realize there are a few short cuts I could take in my STRFIND/STRSUB procedures, but I don't see many steps to save.

How do I cleanly determine the end of the final string?  The data set is ~3500 bytes, which varies slightly (but is published in the header data...)
EDIT:I was playing with it at fixed bytes per STREAMIN, all I need to do is use the .InQueue data to determine how much data to put in each string

What do I do if the text I am looking for falls partly between two SXL's, it would not be found.  Can I re-constitute all the SXL's back together before searching?  That would also simplify the multiple STRFIND steps.

Again, shout out to Jason for guiding, <pushing>, me in the right direction!
« Last Edit: December 20, 2017, 09:39:32 AM by Bolt »

Bolt

  • Hero Member
  • *****
  • Posts: 146
Re: SS memory and pointers
« Reply #42 on: December 20, 2017, 06:39:41 PM »
Here is what I have come up with.

It works pretty good, with a catch.

It will successfully fetch all the data via the API.

When I process the data, it fails about half the time.  On reattempt to process the same data, it works fine.

Please see attached program.

Load the DMD file

Import the Memory data CSV file

Write to Simulator

X14 turns on DMLogger
X0 fetches data via API - V1 will increment success
X15 process the data, but only the dataset corresponding to the appropriate X1-X9 bit status, so pick an X parameter, toggle X15.  V11 is success, V10 and V12 are error counts.  Should make sense in the data view.

I hope someone can tell me why the success rate of the STRFIND based program is not very high.

Any advice welcome.

« Last Edit: December 20, 2017, 07:58:00 PM by Bolt »

plcnut

  • Hero Member
  • *****
  • Posts: 801
    • premiersi.com
Re: SS memory and pointers
« Reply #43 on: December 20, 2017, 07:08:42 PM »
I will try to look this over for you when I get a chance.
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

Bolt

  • Hero Member
  • *****
  • Posts: 146
Re: SS memory and pointers
« Reply #44 on: December 20, 2017, 08:01:29 PM »
I changed my program up one more time, using strictly N100x=!-1 statements to advance through the STRFIND statements and it seemed to have cleared up, running reliably now.

Sorry for the false alarm.  Thanks for your help.