PicoScope 7 Automotive
Available for Windows, Mac, and Linux, the next evolution of our diagnostic scope software is now available.
Hitachi ZW220-7
-
Bruno.Carreira
- Newbie
- Posts: 3
- Joined: Thu Feb 08, 2024 11:26 am
Hitachi ZW220-7
Dear all,
I'm trying to decode a CAN Bus signal on Hitachi ZW220-7 Wheelloader to try diagnose a different machine with a intermittent abnormal update rate on the inlet NOX sensor. I tried J1939 protocol with 250kbit and 500kbit baudrate but without success. Can someone give me some guidance?
Channel A - CAN H
Channel B - CAN L
Chanel C - Current clamp power supply NOX, temp and adblue sensor
Chanel D - Voltage power supply NOX, temp and adblue sensor
Engine Cummins B6.7(EU Stage Ⅴ)
I'm trying to decode a CAN Bus signal on Hitachi ZW220-7 Wheelloader to try diagnose a different machine with a intermittent abnormal update rate on the inlet NOX sensor. I tried J1939 protocol with 250kbit and 500kbit baudrate but without success. Can someone give me some guidance?
Channel A - CAN H
Channel B - CAN L
Chanel C - Current clamp power supply NOX, temp and adblue sensor
Chanel D - Voltage power supply NOX, temp and adblue sensor
Engine Cummins B6.7(EU Stage Ⅴ)
- Attachments
-
- Hitachi_2023_20240212-0002.psdata
- (19.5 MiB) Downloaded 36 times
Re: Hitachi ZW220-7
As you have used A-B you need to use the Invert option in the decoder setup, alternatively create the maths channel as CanHigh - CanLow which would be B-A
You will need to change the Baud Rate to 250kbaud as shown here
You will need to change the Baud Rate to 250kbaud as shown here
Martyn
Technical Support Manager
Technical Support Manager
-
ben.martins
- Pico Staff Member
- Posts: 545
- Joined: Tue May 16, 2017 1:02 pm
Re: Hitachi ZW220-7
Hi Bruno,
Thanks for uploading this capture and hopefully Martin was able to help you to decode your CAN data.
Going a bit further on this and you may already have this information. The transmission rate for the NOx sensors is 50ms. The easiest way to determine the refresh rate is to look for the source address relating to one or both of the NOx sensors, in this case 0x51 and 0x52 for NOx sensor 1 and 2 respectively. When we observe your data we can see that on buffer 1, 0x51 appears at 17.28ms and then appears on buffer 2 at 27.86. Given we have a time base of 5ms/div and 10 divisions on the waveform grid, this equates to 50ms of total time but somehow we have gained 10ms between the two messages.
This can be attributed to the fact there is a trigger on channel C, which may have meant the software waited momentarily before starting the capture and we also have the time that the software takes to send the block of data over to the PC. Going forward it might be worth increasing your timebase to something longer like 200ms/div. This not only gives you streaming data, but more than enough time to see the transmission rate of the NOx sensors. Alternatively you can load the J1939 serial decode guided test which will set the scope for you along with the decoder and the maths. You can see more on this test on our YouTube channel here - https://youtu.be/AJT1hXxhW54?si=gdZuT08WYNCUeN33&t=903.
I hope this helps and please let us know how you get on.
Kind regards
Ben
Thanks for uploading this capture and hopefully Martin was able to help you to decode your CAN data.
Going a bit further on this and you may already have this information. The transmission rate for the NOx sensors is 50ms. The easiest way to determine the refresh rate is to look for the source address relating to one or both of the NOx sensors, in this case 0x51 and 0x52 for NOx sensor 1 and 2 respectively. When we observe your data we can see that on buffer 1, 0x51 appears at 17.28ms and then appears on buffer 2 at 27.86. Given we have a time base of 5ms/div and 10 divisions on the waveform grid, this equates to 50ms of total time but somehow we have gained 10ms between the two messages.
I hope this helps and please let us know how you get on.
Kind regards
Ben
-
Bruno.Carreira
- Newbie
- Posts: 3
- Joined: Thu Feb 08, 2024 11:26 am
Re: Hitachi ZW220-7
Thank you for your support. I was able to decode the messages and apply the link file to recogize the addresses. Now what I want to do is to connect the Pico to the faulty machine and drive it until the fault code appears and get it record in Pico. How can i set a trigger on a faulty NOX outlet sensor CAN message ?
- Attachments
-
-
ben.martins
- Pico Staff Member
- Posts: 545
- Joined: Tue May 16, 2017 1:02 pm
Re: Hitachi ZW220-7
Hi Bruno,
Unfortunately, it is not possible to trigger on decoded messages. This is down to the way we currently decode which happens only once the buffer is full or if the capture is stopped.
I would suggest an option would be to remove the decoder and just have channels A and B for CAN H and CAN L free running. If you're using the guided test this will get you at least 4 buffers, if not more, of CAN data. Once the software hits the buffer limit you will see the number of waveforms no longer increasing. This is where the first buffer is now overwritten and we start a sort of circular buffer. This means that when you notice the fault, warnings on the dash etc, you will need to stop the scope and most importantly save the data. You can then create the decoder and then start looking back through the CAN data.
The alternative is to 'create' a trigger using a simple circuit to create a pulse which you can then measure with the scope on one of the free channels. You can then set a repeat trigger to this channel and move it all the way to the left hand edge or 90% where data will seemingly scroll till you hit a button to create the pulse and then the buffer will complete and then move to the next one.
Another option is using the same technique but apply a mask to the pulse channel. By setting up the mask around the idle signal, an action can be applied so that as soon as the mask is interrupted by the pulse you can get the software to do a number of things such as save all the data, stop the capture and if you are using the latest Early Access build of PicoScope 7 Automotive you can export the decode table. You can see more on this in the following post - viewtopic.php?p=105013#p105013.
Please be careful with actions and the events Every capture and Buffer full. If not set up correctly they will continue to save data and potentially fill your hard drive.
I hope this helps
Kind regards
Ben
Unfortunately, it is not possible to trigger on decoded messages. This is down to the way we currently decode which happens only once the buffer is full or if the capture is stopped.
I would suggest an option would be to remove the decoder and just have channels A and B for CAN H and CAN L free running. If you're using the guided test this will get you at least 4 buffers, if not more, of CAN data. Once the software hits the buffer limit you will see the number of waveforms no longer increasing. This is where the first buffer is now overwritten and we start a sort of circular buffer. This means that when you notice the fault, warnings on the dash etc, you will need to stop the scope and most importantly save the data. You can then create the decoder and then start looking back through the CAN data.
The alternative is to 'create' a trigger using a simple circuit to create a pulse which you can then measure with the scope on one of the free channels. You can then set a repeat trigger to this channel and move it all the way to the left hand edge or 90% where data will seemingly scroll till you hit a button to create the pulse and then the buffer will complete and then move to the next one.
Another option is using the same technique but apply a mask to the pulse channel. By setting up the mask around the idle signal, an action can be applied so that as soon as the mask is interrupted by the pulse you can get the software to do a number of things such as save all the data, stop the capture and if you are using the latest Early Access build of PicoScope 7 Automotive you can export the decode table. You can see more on this in the following post - viewtopic.php?p=105013#p105013.
I hope this helps
Kind regards
Ben
-
Bruno.Carreira
- Newbie
- Posts: 3
- Joined: Thu Feb 08, 2024 11:26 am
Re: Hitachi ZW220-7
Thank you for your support.
Which waveform should I expect from a "abnormal update rate" in the nox sensor?
Regards
A good weekend for everyone!
Which waveform should I expect from a "abnormal update rate" in the nox sensor?
Regards
A good weekend for everyone!
-
Steve Smith
- Pico Staff Member
- Posts: 1594
- Joined: Sun Aug 25, 2013 7:22 am
Re: Hitachi ZW220-7
Hello Bruno and thank you for the feedback
Following Ben’s advice and using the Guided Test configuration for J1939 decoding, we know that 0x51 [ID3 Source Address] is NOx sensor 1 with a transmission rate of 50 ms
With this knowledge we can now use the search feature in the decode table to search for 0x51 and monitor the transmission rate
Below I have used “Wheel Speed” as an example by searching for ID2 (PGN) 65265 where we can see a transmission rate of 100 ms
By clicking on any of the packets in the decode table we are immediately directed to the packet in the graph view where we can view the structure of the signal and analyse for any irregularities
With your machine you would use the same technique but search for 51 within the [ID3 Source Address] column where you can quickly assess the transmission rate (50 ms)
Below is the search feature to use which returns no results as 51 does not exist in our Guided Test file
Where you now have a series of NOx sensor 1 or 2 with an abnormal update rate/ “babbling” you can detect these events in the decode table as they will occur more frequent than 50 ms
Clicking on one such babbling event in the decode table will take you directly to the offending packet in the graph view
At this stage, it would be good to view the differences in structure of the CAN packet between events where the NOx sensor is transmitting at the correct rate, and when babbling
I hope this helps and please feedback for any clarification
Take care…..Steve
Following Ben’s advice and using the Guided Test configuration for J1939 decoding, we know that 0x51 [ID3 Source Address] is NOx sensor 1 with a transmission rate of 50 ms
With this knowledge we can now use the search feature in the decode table to search for 0x51 and monitor the transmission rate
Below I have used “Wheel Speed” as an example by searching for ID2 (PGN) 65265 where we can see a transmission rate of 100 ms
- 1
With your machine you would use the same technique but search for 51 within the [ID3 Source Address] column where you can quickly assess the transmission rate (50 ms)
Below is the search feature to use which returns no results as 51 does not exist in our Guided Test file
- 2
Clicking on one such babbling event in the decode table will take you directly to the offending packet in the graph view
At this stage, it would be good to view the differences in structure of the CAN packet between events where the NOx sensor is transmitting at the correct rate, and when babbling
I hope this helps and please feedback for any clarification
Take care…..Steve