Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Sending Byte List
#11
(08-31-2018, 09:02 PM)CaptRick Wrote: I coded a read method to read the number of sensors get all the data, no matter how big, including the last CRC. The thing is the inverted payloads and payload sizes only refer to the two records/structures in packetized headers,  one is only two bytes the other only 5 with most of the variables just one byte, using the structure to decode it seems irrelevant to me.

No, 3315 is not reasonable, the payload bytes are separate bytes with the inverted one being 255 - payloadsize, the other a byte with the size.

I will see about the IOHandler.InputBuffer.Size property, though I have the code written it would seem easier to read the buffer in it's entirety then deal with the byte array.

The correct solution is to follow the structure of the data. Each packet gives you payload sizes, so that is how many bytes you should be reading, and then you can process what you read. Utilizing the IOHandler.InputBuffer.Size property will not help you, it will only make more work for you. You still have to packetize the raw bytes you receive, so let Indy handle that for you.

(08-31-2018, 09:02 PM)CaptRick Wrote: I have really hit the timing hard, but it's still possible I'm reading the wrong two bytes for the number of sensors, which is the payload that counts. they occur as an array immediately following the second structure.

Let's please stop guessing here. Do you have any documentation about the device's TCP protocol? If not, what kind of device is it exactly?

(08-31-2018, 09:02 PM)CaptRick Wrote: I was playing with AConvert suspecting that might be an endian swapping deal by setting it to true, maybe I made it Big endian and gave myself the headache...  I thought I undid it later, unless it's set to True by default since I never set it explicitly to False. If that is true I can fix it in 10 minutes or less!

Yes, AConvert is True by default. I said that earlier, and you can see it for yourself in the method declaration, too.

(08-31-2018, 09:02 PM)CaptRick Wrote: I also tried to buy the E-book on Indy, but could not figure out how to pay for and download it.

Don't bother. It is very old, it hasn't been updated in many years. Not worth paying for.

Reply
#12
Yep, read the Uint16's using (False), all is perfect so far and I can move on from this vexing problem! Thank you so much rlebeau, (who I think I have read before on other Delphi related sites...) you have been a lifesaver!
Reply
#13
It is a fiber optic strain gauge reader. I do have documentation but it is sparse and proprietary & 'I am not to divulge it to anyone for any purpose'.
My apology, I don't mean to be cagey- I have to. Your help is invaluable.
Sorry I missed the 'true by default' on the read Uint16's the first time... the fact it's there is brilliant.
Though I quickly coded serial lines to handle what it is sending currently I know you are right, I need to read each packet separately so that if the series changes I will handle it. I am reading the number of sensors and setting dynamic array lengths with it so this must involve extensive error checking too.

'You still have to packetize the raw bytes you receive, so let Indy handle that for you.'

I'm not sure what you mean there but it sounds fabulous. Using the Uint16 read I place the data in record variables and a dynamic array sized by the number of sensors value I read last night successfully for the first time. I am interested in the bytes to record and record to bytes routines that I've seen briefly are in Indy, the help that shipped with Delphi 10.2 Tokyo is extensive. In the past I've used pointers to records to overlay the buffer for reading the values, here the records are so small I just read the bytes.

This morning I have the IO working, converting the raw sensor data to useful units, and displaying it in an oscilloscope component as the data streams from the device! I have a test coupon with one gauge I can bend to change the data real time, copied into a number of channels for testing.

Now to enjoy the labor Day weekend here, I have Monday off!
Reply
#14
Remy- If I can't or shouldn't bother to get the E-book, what's the best way to learn about Indy? I'm a mostly self-taught Delphi programmer who reads but then looks for examples & goes in and 'tries stuff' till it works...
Reply
#15
(09-04-2018, 03:35 PM)CaptRick Wrote: Remy- If I can't or shouldn't bother to get the E-book, what's the best way to learn about Indy? I'm a mostly self-taught Delphi programmer who reads but then looks for examples & goes in and 'tries stuff' till it works...

I don't know if the eBook is still available for purchase (contact AToZed to ask), but it is very old, though I'm sure it still has some useful information in it. Other ways are documentation (which is also quite dated), online examples/tutorials, trial-and-error, or just ask.

Reply
#16
The book has not been updated in many years. It does have useful info in it, but I would suggest looking at the online TOC first. It may or may not cover what you need.

I would like to update it some day, but time is a major issue and the software it was authored in is very old as well.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)