Yeah, lets do it Monday. I will be in the office around 0900. Have a good weekend.
Is that Eastern time? I am available at 10:30 EST so I’ll set that time aside for now. Let me know if that doesn’t work.
That works for me sir. 1030 EST
new password?
Kyle,
Shoot me an email when you are ready to connect.
Ready
OK, got the cable fixed and we are receiving data. I’m just not sure what we are getting and I’m not seeing any data in the PLC. I’m just leaving for lunch so how about 1330 we re-convene and see what we can figure out.
I need to find out how to return that other module as well. I’m assuming at this point it was bad out of the box.
Whatever ASCII command I give, I get pretty much the same information back…… But at least it’s talking now.
Hi Russell,
I’m sorry, I got tied up with a case. Trying to figure out the commands that you need to send in order to get the data you need is going to be the challenge. That first example was just for reading the version number. The checksum looked a little more complicated, so that may be the problem. I can log on with Teamviewer and give you a hand later this afternoon or tomorrow.
Kyle
It’s already almost 1600. Do you want to get together same time tomorrow?
New PW:
Kyle,
I have some information on where to start tomorrow from the Veeco vendor. He replies pretty quickly too so if we run into issues tomorrow he can help us out possibly.
See email chain below:
Yes, you’re getting a bad checksum NAK because the checksum is incorrect. For the RT command, it would be:
RTABAD[CR]
(total of 7 characters)
The math would look like:
Take the first 2 characters and form them into a 16-bit number
0x5452 (54 = T, 52 = R)
(if you had more characters you would make another 16-bit with the next 2 characters and add to the previous sum. But RT only has 2)
Then invert all the bits.
0x5452 goes to 0xABAD
Then you make each nibble into its own character in the response.
Let me know if that makes sense,
-Dave