Protocol j1587

For general Flowcode discussion that does not belong in the other sections.
RGV250
Posts: 279
http://meble-kuchenne.info.pl
Joined: Sat Mar 19, 2022 4:53 pm
Has thanked: 25 times
Been thanked: 30 times

Re: Protocol j1587

Post by RGV250 »

Hi,
Something dawned on me last night, you have not said how you are trying to implement this. You made a comment
I can't connect external COM to FC, I think it would be easier that way
.
I am not sure quite what you mean by that but have you decided on a device which will run FC.
I think a microcontroller would be ideal as you can read the serial data into that, looking at your screenshots all the data is 3 characters so that should be easy to migrate to a numeric array usind left$, mid$ as Chipfryer suggested. From there you can have several macro's (one for each MID) and in the macro parse the array, you can ignore position 0 as that has already decided which macro you are in. Read array pos 1 and decide if the data is 1 or 2 bytes and then read the respective elements and calculate the data. Also increment a pointer for the next element of the array to read so in your original data example 084 is one byte so the pointer would then be 3 for the next calculation and then 190 is 2 bytes of data so the pointer would be 6 and so on.

I do have a project that reads data from a string and seperates it like what I think you need so I will have a look to see if I can modify it to give you a bit of a start.

Bob

chipfryer27
Valued Contributor
Posts: 1177
Joined: Thu Dec 03, 2020 10:57 am
Has thanked: 287 times
Been thanked: 417 times

Re: Protocol j1587

Post by chipfryer27 »

Hi

Okay, I can see better what you are trying to achieve.

A couple of more questions.

I'm guessing that when you switch on and start your engine you just have your PC running Serial Tool connected via the UART and it does not transmit anything.

When the "engine" powers up and transmits the dump, Is it a one shot event or does it repeat? If it doesn't repeat can you instigate by sending a command from your PC?

If you know the command to send that returns specific information then things would be a lot easier. If you need to parse through a data "dump" it is a little more complicated. Depending on when/where you start looking, the incoming value could be data or PID or MID etc as they are all just bytes. However the data is in a defined format which you will already know and also the associated parameters.

For example you might have

MID / PID / data / data / PID / data /checksum

The MID/ PID values will be fixed for the line of interest (I am not using real values here) such as

128 / 001 / x / y / 002 / z / checksum where x/y/z are data values

This line will always contain the above with only x/y/z/checksum changing

You could parse through a dump looking for value 128 (MID) and if found the next value should be 001 (PID), followed by two data bytes, then the value 002 (PID) followed by a data byte and checksum. If you found these fixed values in the correct order and the checksum confirmed then you would know it was the line of interest and could use the data. If the MID/PID values and positions etc don't match then the line would be ignored.

If PID 001 was oil temp and 002 was oil pressure from MID 128 then you may have

128 001 123 456 002 321 checksum included in your dump somewhere. You could perhaps create an array called imaginatively "oil" containing seven values. When parsing the dump if it found the value 128 it would place that value in the first position of the array oil[0]=128 and continue to parse. If the next value was 001 then it would place this in the second position oil[1]=001 and continue, but if not it would clear the array and continue looking for 128. Assuming all good we would end up with an array oil[128,001,123,456,002,321,checksum]. If your calculation of checksum matched that in the array then you know the array is good. Now, for oil temp you know the values are oil[2] and oil[3] and pressure would be oil[6] (123,456 and 321 respectively).

There are many ways to look / parse for your particular information, the above was just a simplistic example.

If the scan tool allows you to poll for a particular value(s) then it would be easier to replicate that. Perhaps you could try and capture by monitoring the Tx to see what is being transmitted to the engine? Alternatively perhaps obtain the command from the spec?

Regards

Edit....
I see Bob beat me to a reply :)
I'm not a programming professional, but I'm good with electronics.
That's why many people started using Flowcode

bios33
Posts: 42
Joined: Thu Jun 23, 2022 11:43 am
Has thanked: 12 times

Re: Protocol j1587

Post by bios33 »

This is what I found, a similar example on an old forum.
We receive the string [] from the PC232 interrupt and if 1 byte = 0x80 then we split it into bytes. Something like this
Attachments
1587 read.fcfx
FC10
(22.54 KiB) Downloaded 165 times

bios33
Posts: 42
Joined: Thu Jun 23, 2022 11:43 am
Has thanked: 12 times

Re: Protocol j1587

Post by bios33 »

I'm guessing that when you switch on and start your engine you just have your PC running Serial Tool connected via the UART and it does not transmit anything.
- Serial tools does not transmit anything
When the "engine" powers up and transmits the dump, Is it a one shot event or does it repeat? If it doesn't repeat can you instigate by sending a command from your PC?
- Data is transmitted continuously (cyclically), no need to send commands

That's why many people started using Flowcode
- FC is a very strong program! :)
[/quote]

chipfryer27
Valued Contributor
Posts: 1177
Joined: Thu Dec 03, 2020 10:57 am
Has thanked: 287 times
Been thanked: 417 times

Re: Protocol j1587

Post by chipfryer27 »

Hi

That's the sort of thing and as I mentioned above there are many ways to collect and parse.

In the chart above an interrupt is enabled on RxINT2. Whenever a signal appears at the Rx port the program will branch to the RxInt Macro. This really is the best way to capture incoming data. In the branch you can do what suits you best. This could simply be to capture the byte and store in a circular buffer or in this case capture an entire string for processing later (in Main loop).

Regards

bios33
Posts: 42
Joined: Thu Jun 23, 2022 11:43 am
Has thanked: 12 times

Re: Protocol j1587

Post by bios33 »

Target folder: C:\Users\Admin\Desktop\1587 bios
Source name: C:\Users\Admin\Desktop\1587 bios\1587 read.fcfx
Title:
Description:
Device: ARM.F4.32F411CE
Generated by: Flowcode v10.1.0.38
Date: Tuesday, January 23, 2024 15:53:25
Users: 1
Registered to: bios33 (83925798)
Licence key: CX119E
https://www.flowcode.co.uk
Errors when generating C source code:
1587 read.c : 860 : error : Syntax error
Autoclose turned off

FINISHED


I can’t understand why, everything seems ok

bios33
Posts: 42
Joined: Thu Jun 23, 2022 11:43 am
Has thanked: 12 times

Re: Protocol j1587

Post by bios33 »

bios33 wrote:
Tue Jan 23, 2024 1:55 pm
Target folder: C:\Users\Admin\Desktop\1587 bios
Source name: C:\Users\Admin\Desktop\1587 bios\1587 read.fcfx
Title:
Description:
Device: ARM.F4.32F411CE
Generated by: Flowcode v10.1.0.38
Date: Tuesday, January 23, 2024 15:53:25
Users: 1
Registered to: bios33 (83925798)
Licence key: CX119E
https://www.flowcode.co.uk
Errors when generating C source code:
1587 read.c : 860 : error : Syntax error
Autoclose turned off

FINISHED


I can’t understand why, everything seems ok
I figured out the compilation problem, there was an error in connecting the display, the hex was compiled, I’ll try it now

RGV250
Posts: 279
Joined: Sat Mar 19, 2022 4:53 pm
Has thanked: 25 times
Been thanked: 30 times

Re: Protocol j1587

Post by RGV250 »

Hi,
This might be of use, how I think I would start looking at it anyway. I have used the demo data in your post, it takes a string, picks the individual data and converts to decimal.
It is only an idea, you would need to cater for different lengths of incoming data.
RPI_J1587_V1.fcfx
(23.2 KiB) Downloaded 187 times
Bob

bios33
Posts: 42
Joined: Thu Jun 23, 2022 11:43 am
Has thanked: 12 times

Re: Protocol j1587

Post by bios33 »

Bob
thanks for the example, I'll look into it...

bios33
Posts: 42
Joined: Thu Jun 23, 2022 11:43 am
Has thanked: 12 times

Re: Protocol j1587

Post by bios33 »

Hi!
I rebuilt the project using the example provided by Bob, a very interesting solution, but I can’t start the uart even through the RXINT2 interrupt.
Can you see what I’m doing wrong?
And I can’t start the INJECTOR COM component, does it work?
Attachments
1587_v2.fcfx
(26.67 KiB) Downloaded 167 times

Post Reply