Testbench setup?

[DV52]

Vastech: hmm........ apropos of Uwe's suggestion - isn't T20 /14 on the CAN Gateway a T15 supply pin? As shown on your WD, it appears to be a T30 supply. Wired as per your picture, both the 2 x T30 and the T15 pins are energized together. I wonder whether this might be the problem - just guessing?

On the RNS300 in the car, the T15 rail is generated via an electromechanical relay (J329) via the BCM. Perhaps install a single throw, single pole switch in the T30 supply to simulate a T15 signal - maybe (i.e. allow the T30 circuits inside J533 to stabilize before sending the T15 signal)?

If this still doesn't work and as indicated previously, the module wake-up CAN message on the MQB model Golf is created from the ignition key action via the steering module. Not sure if this is the same for your car, but the WD for a mk5 (which uses the RNS300) has the ignition/starter switch directly connected to J527 (the sterring column module). So exactly the same as the Golf mk7.

Don

 

[ibis_white]

Maybe pin 13 - Connection for ignition-key-controlled switching on and off (S contact) needs to be connected to 12v??

See link below:

https://workshop-manuals.com/volksw...2_8-pin_for_voltage_supply_wires_and_can_bus/

 

[Riley]

Greetings from Seattle Washington,

This is my first post and glad to be here. I have read this thread a dozen times and am just starting to cobble together my first test bench for Audi B6 chassis cars. Thank you all for the contributions. I am getting excited!

*rubs hands together*

Riley

 

[Jack@European_Parts]

Does the radio power up on the bench? If not, it may be looking for a CAN message from another module, like a "virtual Terminal 15".

-Uwe-

Yup usually from BCM or Cluster too, right guys?

One day there was a fine Schwarz or Blau wire......

 

[AINils]

Hey guys tried to activate pACC but will try it first in Testbench. Does anybody of you can give me Part Nr of ACC Plug for 3QF907572 (3QF907561)

 

[_Val]

4F0972708 (8pin black connector) for 3QF907561A.

 

[Ronaldo]

Well, I suppose one could monitor a real J527 to see what CAN telegrams it produces that correspond to the various turn signal switch states (or change of states) and then substitute something some smaller device capable of simulating them, but that seems like far more work than just wiring up a real J527.

-Uwe-

Thanks to all who posted their experiences with a testbench. I've built a simple Arduino based circuit and programmed it to inject the Klemmen_Status (terminals' status) message in the CAN bus in order to make the ECUs believe ignition is on, so I don't have to buy a real J527 and can put the testbench circuit in a small box. In the next days I plan to make some more testing with different ECUs to see if I can make all of them to "wake up", but I think there are good chances it will work. I will post here the details if someone finds it useful.

 

[jf1]

Thanks to all who posted their experiences with a testbench. I've built a simple Arduino based circuit and programmed it to inject the Klemmen_Status (terminals' status) message in the CAN bus in order to make the ECUs believe ignition is on, so I don't have to buy a real J527 and can put the testbench circuit in a small box. In the next days I plan to make some more testing with different ECUs to see if I can make all of them to "wake up", but I think there are good chances it will work. I will post here the details if someone finds it useful.

interested!

 

[Ronaldo]

interested!

The prototype was developped for the MQB platform, but I think it may work for other platforms as long as you have the right data for the CAN bus messages. I've just tested the circuit with 3 ECUs: a Door Control Unit, a Parking Aid and a TPMS, they are connected to different buses and all worked but I have no other modules here to test (I also had an ABS module, but it was replaced in my car exactçy because it stopped communicating, so I couldn't count on it). Maybe some pros in the Forum will be interested in testing with more modules and post here their results.

The circuit is basically an Arduino and a CAN bus interface, connected to the convenience CAN bus pins (5, 15) on the J533 Gateway. The diagram below is similar to what I did (connection to INT pin on the interface is not necessary for the code I used):

The code I wrote to run in the Arduino generates a "Klemmen_Status_01" on the CAN bus. It's a simple message with the Id 0x3C0 which, in a real MQB car, is transmitted every 100ms and it contains 4 bytes of data:
- first byte is a checksum;
- second byte contains a sequential number that increments from 00 to 15 in each message, then returns to zero;
- third byte contains the flags corresponding to terminals (Klemme) S, 15, X and 50. I've set the bits corresponding to S and 15 on (ignition switch on) according to what I've captured by collecting CAN bus traffic;
- fourth byte is always zero.

The code tries to simulate the Klemmen_Status_01 messages exactly as they are sent on the CAN bus in a real car. It seems that ECUs connected to the gateway "wake up" even if only one of the 16 sequential messages is sent, and not necessarily at the 100ms interval and some modules seem to continue on even if they stop receiving the message for up to 4 seconds but since I'm not sure about all possible modules and the implementation of the complete message set is so easy, I kept it in the code.

Here's the code:

/*
 * Terminal status CAN bus message generator
 * 
 * Generates Klemmen_Status_01 messages for MQB platform
 * 
 * Coded by Ronaldo Cordeiro - cordeiroronaldo@hotmail.com
 * 
 * Uses MCP_CAN_lib-master - By Cory J. Fowler 
 * https://github.com/coryjfowler/MCP_CAN_lib
 */

#include <mcp_can.h>
#include <SPI.h>

#define KLEMMEN_STATUS_01_ID 0x3C0

unsigned char kStatusBuf[4] = {0x00,0x00,0x03,0x00};
unsigned char checkSum[16]  = {0x74,0xC1,0x31,0x84,0xFE,0x4B,0xBB,0x0E,0x4F,0xFA,0x0A,0xBF,0xC5,0x70,0x80,0x35};
int i=0;

MCP_CAN CAN(10);

void setup()
{
  Serial.begin(115200);
  CAN.begin(MCP_ANY,CAN_500KBPS,MCP_8MHZ); 
  CAN.setMode(MCP_NORMAL);
}

void loop()
{
      kStatusBuf[0]=checkSum;
      kStatusBuf[1]=i;
      CAN.sendMsgBuf(KLEMMEN_STATUS_01_ID, 0 , 4, kStatusBuf);
      i++;
      if (i>15) i=0;
      delay(100);
}

/*********************************************************************************************************
  END FILE
*********************************************************************************************************/

Suggestions and corrections are very welcome.

 

[DV52]

Thanks to all who posted their experiences with a testbench. I've built a simple Arduino based circuit and programmed it to inject the Klemmen_Status (terminals' status) message in the CAN bus in order to make the ECUs believe ignition is on, so I don't have to buy a real J527 and can put the testbench circuit in a small box. In the next days I plan to make some more testing with different ECUs to see if I can make all of them to "wake up", but I think there are good chances it will work. I will post here the details if someone finds it useful.

Ronaldo: Don't get me wrong - I reckon your device is a sublimely elegant solution to generating a "wake-up" message and (as you say) it does indeed obviate the need to "buy a real J527 and can put the testbench circuit in a small box".

But there is a down-side in not including a J527 module on a testbench -perhaps? I say "down-side", but this depends really on what the objective is for creating the test-bench in the first place.

At least on MQB modules, J527 appears to take a prominence in the CAN network structure that goes well beyond steering wheel activities. For example (and as was the focus of your brilliant device) - it generates the CAN bus(es) wake-up message, but it also initiates for the BCM (and other modules like hex55 and LCM s), the high-beam function. And, J527 is responsible for initiating the turn-signal messages (which the door modules and BCM use) and the wiper and washer signals. Plus, as I found to my chagrin in the early days of my test-bench development, the path through J527 from the ignition "C" switch status was important to J285 for the instrument module's understanding of how to operate the FIS and the warning messages.

But without a doubt and again, a mighty effort in designing/building your brilliant device - it demonstrates an intellect and an intimacy of CAN knowledge that makes me pea-green with envy!! I suspect this is just the beginning of many more successes in the future (please don't stop sharing your learnings).

Don

 

[Ronaldo]

Thank you so much Don for your comments! Actually I'm just beginning to use a testbench so I have close to zero experience on what can be useful or not for a testbench user, so input from experienced people is much apreciated.

The idea behind a creating a programmable device to simulate CANbus messages wasn't really to restrict it to generating the Klemmen_Status, but also extending the project in the future to create other messages, not only the ones generated by J527 but also signals like car speed, steering angle, gas pedal position, engine RPM, etc, something like a simplified version of a professional simulator like https://www.digiteqautomotive.com/en/product/cansim4

The first improvement I though of was to add a switch to the project that could select from ignition switch on-off-inserted. It would add a simple switch to the box. I'm sure it's perfectly possible to also generate the CAN bus messages corresponding to all functions of the J527, indicators, wipers, high-beam, cruise control, but in this case I fully agree with you that a real J527 module could be a better idea because a simulator module would need to have a panel with too many buttons and could result in a device harder to operate than a real and intuitive steering wheel module.

Anyway, I see this prototype as a first version of an evolving project and comments from knowledgeable people are very useful and encouraging. Thanks again for your comments!

Ronaldo

 

[jf1]

Thank you so much Don for your comments! Actually I'm just beginning to use a testbench so I have close to zero experience on what can be useful or not for a testbench user, so input from experienced people is much apreciated.

The idea behind a creating a programmable device to simulate CANbus messages wasn't really to restrict it to generating the Klemmen_Status, but also extending the project in the future to create other messages, not only the ones generated by J527 but also signals like car speed, steering angle, gas pedal position, engine RPM, etc, something like a simplified version of a professional simulator like https://www.digiteqautomotive.com/en/product/cansim4

The first improvement I though of was to add a switch to the project that could select from ignition switch on-off-inserted. It would add a simple switch to the box. I'm sure it's perfectly possible to also generate the CAN bus messages corresponding to all functions of the J527, indicators, wipers, high-beam, cruise control, but in this case I fully agree with you that a real J527 module could be a better idea because a simulator module would need to have a panel with too many buttons and could result in a device harder to operate than a real and intuitive steering wheel module.

Anyway, I see this prototype as a first version of an evolving project and comments from knowledgeable people are very useful and encouraging. Thanks again for your comments!

Ronaldo

Getting that message worked out is exactly where I had previously left off with my bench setup - very helpful!

I use a Raspberry Pi 4B + PiCAN2 Duo board for CAN bus comms, your code should translate over easily.

 

[jonese]

I've setup a test bench from a wrecked 2011 Jetta SportWagon (getting them from the auto wreckers allows you to grab the connector and about 6 inches of wiring harness, much easier way to hook them up). I've currently got the gateway working, but also have the BCM ready to hook up. There is no ECU in this setup.

How does the licensing work with the HEX-V2 in this setup? What does VCDS consider a licensed entity (partial CAN bus of a car)?

I didn't do any recoding, just read some values so my license counter didn't increment, but I'd like to do a lot more in depth poking around at a later date. I have one license for my real car, but I'm not so interested in using another VIN license for my test bench.

 

[Uwe]

I have one license for my real car, but I'm not so interested in using another VIN license for my test bench.

Without an ECU or a cluster, there's likely nothing that the HEX-V2 or VCDS can obtain a VIN from in that setup, so I doubt VCDS will ever ask you if you want to store/register a VIN while you're connected to it. But if it does, be sure to decline.

-Uwe-

 

[DV52]

Uwe: your response raises the profoundly interesting question as to which of the few KEY modules on the CAN network actually defines a VAG car (for diagnostic purposes specifically, but also in general)?

I mentioned earlier (I think) that on my test-bench ALL modules were sourced from different cars (cheapest option for sourcing modules). Therefore each Key module has a different VIN. Now, the curious thing is that VCDS seems to report the VIN in the hex17 module as the definitive number for the virtual car (in the auto-scan report) - but even more interesting, another diagnostic device appears to use the VIN in the hex19 module !

So, is this fundamental matter simply a manufacturer specific decision - or is it enshrined in the tome-like pages of an arcane industry Standard somewhere?

Don

 

[Uwe]

Don,

No, I don't think there's an "industry standard" for this. Historically, the place that VINs have been found are in the ECU and the Immobilizer. The latter is most often part of the cluster. This has been the so since the advent of Immo-3 between MY 2000 (when it first appeared in the Audi A8) and 2002 (when it became almost universal in VAG cars). Having the VIN also present in the Gateway is something relatively new; in VWs probably only since the MQB chassis. I'm not sure when it started in Audis; they've had CP for a lot longer, but without going back and reading old SSPs, I'm not sure whether the GW was the CP master in (for example) a 2005 4F chassis car.

-Uwe-

 

[jonese]

I have my workbench setup (purely for personal playing/learning with VAG CANBUS). I can talk to the modules (ECU, Instruments, GW) via the ODB2 port and on their native CANBUS's, no issues.

However, I've recently added a BCM (PQ35) to the convenience/comfort bus. I've added power to all the necessary connections that would seem reasonable from following the schematic, and applied power from what would be the ignition inputs, but I can't get the BCM to talk. I can see the GW sending messages (at 100 kbps), I can see the BCM power up CANBUS interface to ~6V, but there's nothing coming from it or does it respond to VCDS querying the $09 module.

In reading around, I see:

Note: Make sure to have all Doors unlocked, otherwise this Control Module may not communicate with the Scan Tool/VCDS.

I'm I running into this issue? Do I need to add a J386 Driver door control module or emulate what messages it sends during an unlock button press? Or I'm I missing something else?

 

[DV52]

jonese: Hi. PQ35 BCM..........hmm?

I'm more familiar with MQB platform vehicles, but just looking at your picture, it's not immediately obvious how your set-up generates its T15 rail. A PQ35 vehicle uses exactly the same method as MQB car in that the BCM generates lots of DIN 72552 voltages including T50, T75 rail voltages AND especially pertinent for a test-bench T15!

In early versions of my test-bench that didn't include a BCM, it was sufficient that I used a single-pole-singe-throw to create a T15 supply from the T30 rail. However, when I subsequently installed a BCM, this solution was no longer appropriate because the BCM itself generates the T15 rail.

My quick look at the WD for a PQ35 car suggests that the BCM controls 2 x T15 relays (J681 and J329) using pin T52B /12 depending on the model.

The reason why I mention T15 voltage is because on the other modules in my early test-bench incarnation, the appearance of a T15 voltage was sufficient to wake-up the module and to have the other CAN buses communicate through J533. However, I found to my chagrin, that a different process was needed to wake-up the BCM - it was necessary to simulate the ignition key switch-on process via the steering wheel module (see the picture below). Of course, in addition to the inclusion of the hex44 module, I then needed to simulate the actual ignition key switch (again see picture below). My assumption is from the need for these separate pieces of equipment that the BCM wake up signal is transmitted by a CAN message from the steering wheel module.

Of course, once the BCM was added to my test-bench, I was able to generate the T15 voltage in the proper way - I used an old 12volt relay that was triggered by the appropriate BCM pin and I removed the original single-pole, single-throw switch.

The same may be needed in your PQ35 case-perhaps?

Don

PS:As you can see from my picture, I also have a driver-door module installed on the test-bench, but this was not needed to wake-up the BCM (I added the door module for an entirely different purpose)

 

[jonese]

Thank you for your thoughtful response.

The various T15 T30 T31 and such were all injected with alligator clips attached to the +12V line (temporarily until I figured out what is required). I have no separate T15 (switched), it's all either ON of OFF for the overall setup. I'll take a look at the ignition switch / steering wheel module. I thought it was just a 12V signalling from it to the BCM that would wake up the BCM, but if it's also over the CANBUS, then that's probably where I need to look next.

It's a bit cold here at the moment (-15C) so I'll have to wait a bit before I head out to the salvage yards again. I'd would have preferred to go with the MQB platform, but it's too new for the yards that I've been shopping at.

Thanks again!

 

[DV52]

Thank you for your thoughtful response.

The various T15 T30 T31 and such were all injected with alligator clips attached to the +12V line (temporarily until I figured out what is required). I have no separate T15 (switched), it's all either ON of OFF for the overall setup. I'll take a look at the ignition switch / steering wheel module. I thought it was just a 12V signalling from it to the BCM that would wake up the BCM, but if it's also over the CANBUS, then that's probably where I need to look next.

@jonese: Here's a very simplified WD from a mk6 (PQ35 model - as I understand) showing the arrangement for J527 :

The CAN high/low wires connect to the same bus as the BCM (I think).

You can deduce the switching logic for the "ignition key withdrawal lock solenoid" from my WD (look at the switch terminals), so you can simulate the the box underneath J527 without sourcing the piece. There's intelligence about the purpose of each terminal as the last entry on the J527 pin descriptors. (the 2 x terminals at the extreme right-side can be ignored -I think)

It's a bit cold here at the moment (-15C) so I'll have to wait a bit before I head out to the salvage yards again. I'd would have preferred to go with the MQB platform, but it's too new for the yards that I've been shopping at.

hmm........ just coming-out of 42C days here - send down all the white stuff that you can -please!!