Go Down

Topic: rsapi.dll with Excel VB, replace with arduino?? (Read 1 time) previous topic - next topic

Hiddenvision

#15
Jun 27, 2019, 06:26 pm Last Edit: Jun 28, 2019, 05:37 pm by Hiddenvision
No believe me I fumble my way thru most things, nothing wrong with it.
"Knowing" is way too overrated... And you learn far more than just getting the correct answer first.!

Those pin numbers mostly talk about the Max232 chip.
Apart from where I say pin 2 on a 9way.

On a 9 way RS232 connection
Pin 2 is the data into PC
Pin 3 is data out to device

The only reason why the interface may not work is RX and TX being reversed, the MAX232 chip popped or one of those other doofers on there is broke.

I would normally say, it won't harm to try (switching Rx & Tx), but obviously take any perceived risks you can deal with.

To test the interface just open a terminal program.
You would prefer not to have the PCU connected during the echo tests so either
apply some power (5-8v) to the red/black leads or unsoldier the Rx & Tx wires .

Without Max board connected
Test1: Short out pins 2 and 3 on the serial socket, type something into the terminal and see the echo.

Plug in the max board
Test2: Short out pins 13 & 14 on the max. type and see echo.?
Test3: Short 11 & 12 to test the TTL side of things, ECHO.??
Depending how that went you could test the level switching part by
Test4: Shorting Rx & TX dots and trying the echo test once more.



Re the Prolific USB to 232. It is the Max chip that generates the boosted voltage all based on the series of caps you see. Some devices get to +13v -13v but it is not so strict. Even some laptops struggle to reach 8 or 9v+-. And you strictly do not need negative volts the PC will be happy to see data bounce between 0 and 5v. in the old days before serial was built in you would bitbang the stuff in and out without needing max232, just a couple of resistors and you invert the logic levels or ones and zeros. But yes the Max232's or simular do all that for you.

Also not 100% if the 5v TTL levels are flexible by altering the input volts. Do they make 3.3v devices or just run them at lower volts.? A quick read of the datasheet will give that game away. Well the answer is NO 6v is the upper limit so it is just a 5v or lower device.
That's where a suitable level-shifter steps in.

If by purchase a new dongle, are you talking about the Max232 board.
You would not want to be spending hundreds on such a thing.
They are dollar and cents parts.


pissten

#16
Jul 04, 2019, 04:42 pm Last Edit: Jul 28, 2019, 08:44 pm by pissten
Hi Hiddenvision,

I've been able to establish communication to the PCU, using a arduino uno as usb to ttl converter.
With the help of free serial monitoring tool, I've recorded some data received from the PCU.
I read from the Excel macro that the SENDBYTE's that was used were, (37) (77) and (114).
In the log file you'll see the data received for each of these trigger strings.

I feel that I can recognize the data received when sending (77) and (114),
but the data I'm most interessted in, I'm not able to make sense of. If I send (37) to the PCU I should
receive Real-Time Data, like RPM and battery voltage etc.. This Is what I receive in ASCII data:

<code>
.....,...,.ë.,...,.·þ,.E.,...,...,...,Ë..,Ë..,Ë..,½..,½..,Ç..,È..,È..,...,...,...,...,
..,.Ò.,...,...,
</code>

Hiddenvision

Hi C,

Great news on getting the communications going.
I had a quick read of the vbs macro code in the xls file.
I knew there was more than the macro original text file you posted.

Two ways to go from here.
Either write a bit of Arduino code to emulate the PCU actions.
Something simple to spit out the various response strings to the requests.
That way it will be easy to interact with the software on the bench rather than the boat.
In doing that you will also fully understand how the packets are constructed.

You may also perhaps take the really lazy but challenging task of converting the VB into Arduino/C.


From what I read there is 25 data packets for the (37) request.
Each packet is 4 bytes long mostly.

Are you getting back about 100 bytes.??
If so then they may just need converting to a value.
See the Sub GetValue(valul) or  Sub Getnumber(parf1, parf2, parf3, vax)


But that would be my 1st approach, get an Arduino responding to the original software as if it were the PCU. then you can edit the response data packets and see if the results make sense on the proper software.

You will then also have an invaluable simulator tool.

With the original Max232,
Just check if the 5v regulator is still working.
Then try those loopback tests, if testing the TTL loopback fails and it has 5v then the max has failed.
Simple to replace.
It is a handy Max driver as it drives the line volts up a little but in reality none of that may matter.


Hiddenvision

Looking at the log I got a bit confused as to what was the response to what.

Oh you need to also perhaps view some of the data in hex rather than character.
You will need to know the values of the 4 byte blocks to check the math.

So the same in Hex would be like
Code: [Select]

SENDBYTE (37) = "
53 45 4E 44 42 59 54 45 20 28 33 37 29 20 3D 20 22


2E2E2E2E
2E2C2E2E
2E2C2EC3
AB2E2C2E
2E2E2C2E
C2B7C3BE
2C2E452E
2C2E2E2E
2C2E2E2E
2C2E2E2E
2CC38B2E
2E2CC38B
2E2E2CC3
8B2E2E2C
C2BD2E2E
2CC2BD2E
2E2CC387
2E2E2CC3
882E2E2C
C3882E2E
2C2E2E2E
2C2E2E2E
2C2E2E2E
2C2E2E2E
2C0D0A2E
2E2C2EC3
922E2C2E
2E2E2C2E
2E2E2C22

0D0A0D0A


There is more than 25 x 4 byte blocks.

I am sure you can set breakpoints in the macros and check data in real time following the calculations thru to the final result.


pissten

I will give it a try tomorrow :) Although I've tried several sketches to receive data from PCU to arduino, without success. I've never really tried what you suggested, to make arduino emulate the pcu.

Do you have a *.ino file that would fit the task? Parsing the data packets to each variable etc.. (rpm, bvolt, map, )

Thanks
Christian

pissten

Looking at the log I got a bit confused as to what was the response to what.

Oh you need to also perhaps view some of the data in hex rather than character.
You will need to know the values of the 4 byte blocks to check the math.

So the same in Hex would be like
Code: [Select]

SENDBYTE (37) = "
53 45 4E 44 42 59 54 45 20 28 33 37 29 20 3D 20 22


2E2E2E2E
2E2C2E2E
2E2C2EC3
AB2E2C2E
2E2E2C2E
C2B7C3BE
2C2E452E
2C2E2E2E
2C2E2E2E
2C2E2E2E
2CC38B2E
2E2CC38B
2E2E2CC3
8B2E2E2C
C2BD2E2E
2CC2BD2E
2E2CC387
2E2E2CC3
882E2E2C
C3882E2E
2C2E2E2E
2C2E2E2E
2C2E2E2E
2C2E2E2E
2C0D0A2E
2E2C2EC3
922E2C2E
2E2E2C2E
2E2E2C22

0D0A0D0A


There is more than 25 x 4 byte blocks.

I am sure you can set breakpoints in the macros and check data in real time following the calculations thru to the final result.


I put the response inside " "

It should be possible to cross-reference the data between the excel macro and the data packets in the log file. But I can't seem to make any usable of the response from the "Real-Time data" (SENDBYTE 37)

The Calibration Sheet in the Excel macro (SENDBYTE 77), will give all the values from the chart in a ASCII response though. Just copy the response from my log into a online ASCII to DEC converter and you will see that most values can be cross-referances to the Calibration sheet.

Hiddenvision

Hi C,
Looking at the Macro Sub ReadData(icou)

You will see that it first waits for a sync word of 2217
It will try 4 attempts from first peek.

then after that was received it scoots off to Flag3: and reads in those 25 sets of 4bytes.'
Code: [Select]


Sub ReadData(icou)
     Ltries = 0
Flag1:
     parms1 = READBYTE                    ' sync byte1 is 22
     Ltries = Ltries + 1
     If Ltries > 4 Then icou = 31567: GoTo Flag8
     If parms1 = 22 Then GoTo Flag2
     GoTo Flag1

Flag2:
    Ltries = 0
    parms2 = READBYTE                    '  sync byte is 17
    Ltries = Ltries + 1
    If Ltries > 4 Then icou = 21345: GoTo Flag8
    If parms2 = 17 Then GoTo Flag3
    GoTo Flag1
   
Flag3:
    Call GetValue(RPM)                                        ' field 1

    Call GetValue(ExhTemp)                                    ' field 2
    ExhTemp = ExhTemp * 2

    Call GetValue(Map)                                        ' field 3
    If Map < 0 Then Map = 65536 + Map

    Call GetValue(engtemp)                                    ' field 4

    Call GetValue(Bv3)                                        ' field 5
    Bvolt = Bvolt * 0.95 + Bv3 / 20
   
    Call GetValue(AirTemp)                                    ' field 6

    Call GetValue(Time1)                                      ' field 7
    Time1 = (Time1 / 1000.002)

    Call GetValue(Time2)                                      ' field 8
    Time2 = (Time2 / 1000.003)

    Call GetValue(Time3)                                      ' field 9
    Time3 = Time3 / 1000

    Call RFu(Fuel)                                            ' field 10
    Fuel = Fuel - 1

    Call RFu(Fuel2)                                           ' field 11

    Call RFu(Fuel3)                                           ' field 12

    Call RFu(FuelM)                                           ' field 13

    Call RFu(FuelA)                                           ' field 14

    Call RFu(FuelB)                                           ' field 15

    Call RFu(FuelC)                                           ' field 16

    Call RFu(FuelD)                                           ' field 17

    Call GetValue(PumpPower)                                  ' field 18
    PumpPower = PumpPower / 10

    Call GetValue(pump_current)                               ' field 19

    Call GetValue(Time20)                                     ' field 20

    Call GetValue(SteamWheel)                                 ' field 21

    Call GetValue(TimeSec)                                    ' field 22
    If TimeSec < 0 Then TimeSec = TimeSec + 65536

    Call GetValue(ProgramVersion)                             ' field 23

    Call GetValue(opMode)                                     ' field 24

    Call GetValue(PrimerSwitch)                               ' field 25
   
  '  end of data stream -----------------------------------------------
 


I did not see that 2217 sync word in the captured data.

It will be simple to provide the basics to start an emulator.
opencom, listen for bytes and send out the required data that the program is expecting.

I will wrap something up as a starting point.
But it will need on hand editing once you start to work out what is what, so best you do most of it.

Let me download the rsapi file then I can run it



Hiddenvision

#22
Jul 05, 2019, 12:14 pm Last Edit: Jul 06, 2019, 08:16 pm by Hiddenvision
Ok So this interacts with the software.
Just to note that rsapi seems to ignore bytes that are 0.

Terrible looking code example but it works.!
I needed to edit the macros a little to add a Delay(1500) when the comport is opened.
Remember the Arduino normally resets when the port is opened.
That reset may make it miss any SENDBYTE(X) that happen just after the port opens.


SEE LATER POSTS FOR LATEST FILE.

pissten

Ok So this interacts with the software.
Just to note that rsapi seems to ignore bytes that are 0.

Terrible looking code example but it works.!
I needed to edit the macros a little to add a Delay(1500) when the comport is opened.
Remember the Arduino normally resets when the port is opened.
That reset may make it miss any SENDBYTE(X) that happen just after the port opens.



Hi H


THIS IS JUST AWESOME! :D
If this code is terrible looking, that just tells me how bad I am with arduino coding. Because this looks really good to me! :D

I also did the changes in the macro as you suggested, I and communication between Arduino and Excel seems to work! :)

I can't thank you enough!
Now the testin begins :D


Thanks
Christian

Hiddenvision

#24
Jul 06, 2019, 02:53 pm Last Edit: Jul 06, 2019, 08:17 pm by Hiddenvision
No Worries C,

Actually that first version was full of holes.
This one is a little better.

This pretty much simulates some parts of the softwares needs.
Remember that "OPENCOM" may actually restart an Arduino so if you get no or slow response you may want to add the line DELAY(1500) after any OPENCOM, not the best but it wont harm.

I was trying all sorts of things so the code may look messier but with luck it will point you in directions you never thought possible or worthwhile. Using some pots or switches you can start to simulate some of the controls/messages and visualise it on the regular software.


How you structure things or what variable types you use is not something I can directly advise on.
It's a personal thing I guess, there is always many ways to skin a cat but some ways can be conventionally or programmatically better. I know little about all 3.

Anyway, this one should replace the previous PCU_emulator.ino.

I have edited the XLS(vbs) stuff a little but have not included the file as I do not want to break how it works on your real device. If you find the Arduino is not responding shout I can send this edited xls file..

SEE LATER POSTS FOR LATEST FILE.

Hiddenvision

#25
Jul 06, 2019, 08:02 pm Last Edit: Jul 08, 2019, 08:37 pm by Hiddenvision
Hi C,

Last edit for now,
I also include the renamed xls sheet.
the XLS is mostly the same but with a few edits and a bit of formatting

In this Ino I edit the RPM and opmode so you can see them change on the screen.
RPM increments per packet requested,
opmode increments once every 100 packets.

I was going to simply use the EE as a place to store the data.
Some of the replies are got from the EE, so you can see the various efforts working.
But the address's it sends out on progword or progbyte is not easy to use instantly. I had a go but it was not right.
The programming feature is responding correctly though not actually saving the received data.


To find how each number is stored, encoded and presented you will need to step thru the vbs code.
RPM for example 4 bytes {x1,x2,x3,x4}
x1x2 =  16 bit value
x3 = multiplier
x4 unused mostly

As I think you mentioned the Pot values are simply in Text from 99 to -99 with a comma at the start.

Oh with the XLS sheet,
I added a central opencom function.
Just easier to set the port details and tweek that delay if needed,
ALL the original OPENCOM's now call the "openthecoms" sub.
I mention that cos I had it set to com3, you may need to change that.

SEE LATER POSTS FOR LATEST FILES.

Hiddenvision

#26
Jul 08, 2019, 08:32 pm Last Edit: Jul 09, 2019, 07:33 pm by Hiddenvision
Trying to upload another version but it is failing.
Urgh, something to do with the ino file.
So I zipped it.

Nothing much has changed, a few edits to make it read better perhaps.

SEE LATER POSTS FOR LATEST FILES.

pissten

Hi H,

I am so incredibly impressed with your work! Seems that you have figured out the entire VBA? :O

The only thing that is not read correctly on my computer, is the Serial Number, which seems to expect 7 bytes and not a string. I can see that the serial number is spit out as a whole number from the PCU, but I can't find any calculations in the macro for it? When editing the PCU emulator.ino to print a string the Calibration Sheet stops with a VBA error message :/

And the program version is not registered in the calbration sheet, but only in the Real Time Display sheet. So It parses the data in different ways on each seperate sheet? :/


Since you have figured out how the data is expected to be received in the excel macro, would you already know how to parse the data directly from the PCU?

I thought that I had sent you a PM, but I can't seems to find it as a sent message. So It may never been sent :/ just wanted to tell you that I would like to make a donation for your time and help! Do you use paypal?

I'm just so greatfull, because this is such a important mission for me, but don't have enough skills to poll it off by my self.



Best regards
Christian

Hiddenvision

Hi C,
You did send a PM but I can't access them on this browser.
I saw your offer but that is fine. I thank you for the offer though.

Yes the VB stuff is my native language, easy to follow what is happening there.
Terrible code, if I were to comment, but hey it works for them so even terrible code is worthwhile.

Oh Re some numbers not showing,
Un-comment the  Write_EEDATA(); bit in the setup for the first run on a new device.
Just program, let it run and re-comment the line again compile and program
The empty eeprom will throw up some errors in the xls due to the default 255 of the received data.
make sure to comment it back out after to save on reset time.


Most of the formatting of the numbers is pretty clear.
RPM, BVolts and those similar fields all use the 4 byte packets.
First two bytes is just a 16bit value, the third byte is used as a multiplier or divisor.
The fourth byte is collected but appears unused in the Macros.
Then sometimes the value is manipulated to present a final value on screen.

There was a couple of SET functions in the Ino code showing a blunt method of creating the packets from regular numbers.


Parsing the data directly from the PCU should be easy, you just have to get to know the values and reference the VB stuff to see any formulas.
but very simple as long as the Arduino does not take too long to do any calculations
I will have a breeze thru later and see if anything is tricky.


So Onwards....
It would not take a moment to spin up some new code to just
open a "soft serial" port on the Arduino and spit out a 144 request
You should then get the serial number back each time.
If you have used a softserial port (and it works) you can simply echo debug stuff back to the terminal via the normal serial.print.


If you find that the PCU is still not responding to the Arduino code then it could be that Higher voltage on the max232 thing biting you. We can go there when/if you have the problem.

In theory you should be able to hook the PCU wires to the pins of the Arduino/Atmel chip.
They are both serial at TTL logic but with different voltage.

I would use a level shifter to comfort the HIGH VOLTS you see on the lines, that is what the bits on that original Max232 board are doing. Or you could jig it with some resistors to protect the Arduino a little.

The little level converter boards on ebay are so cheep it is worth trying one of those first.
Or get that original dongle/max232 board working again and you could simply drive that with another max232 connected to the Arduino softserial pins.

Once you have the PCU responding to the Arduino code then simply expand it to be a bridge for any serial traffic to and FROM the PC/xls sheet.

Listening for data from the PC and echo it to the PCU
Listen for data from the PCU and echo it to the PC
Doing that you can intercept and decode/encode any of the data passing thru.
still using the XLS as the method of testing if your decoding of the numbers match.

Once that is nailed you're set.!!

What are you doing with the data you read from the PCU,?
are you putting it on a display or transmitting it somewhere else.?
You may have already mentioned that.! I'll check.




Hiddenvision

#29
Jul 09, 2019, 07:31 pm Last Edit: Jul 11, 2019, 01:32 pm by Hiddenvision
So time for another edit.??

I added in some softserial bits to use pins 10 and 11
I also added a timeout for nodata  reception on the softserial port.
You may need to adjust that for real world use.

the idea is that it will open the port, send out a request for serial number and if it gets one it will write the first 6 bytes received to the EEProm.
then it will do everything it was doing before but using the new serial number received.

Obviously I do not have a PCU to test but I guess I could just program another Arduino to pretend to be one to see if it actually works.

Let me add those files.

SEE LATER POSTS FOR LATEST FILES.

Go Up