Crankshaft position sensor simulation

[Stijn]

Dear labVIEW users,

as a last year graduate on the KDG I got to realise a last year project.

The target is to simulate automotive sensor signals and send these to the ECU ( electronic control unit ) of the motormanagementsystem, this ECU will interpret this signal as actual circumstances in the car while he's driving and while the engine is running.

All the sensorsignals has been simulated but now we've got to simulate the crank shaft signal, this is a inductive sensor that stands next to a flywheel, on the flywheel there are 35 theeth and after the 35 theeth there is 1 thooth gone. When passing a tooth the inductive sensor generates a sinus, here where the thooth is gone after passing 35 theeth the inductive sensor generates a sinus with a bigger amplitude (this is only physical) and a lower frequency. The ECU triggers on each falling edge of the sinussignal, here where the tooth is gone it will take a longer time before it triggers a falling edge, this is a reference point for the ECU for knowing the position of the cylinders in the engine.

As attachment I've uploaded what we've got right now and a picture of how it should be when it's perfect.

The waveform graph in the VI shows with every frequency that after 35 pulses 1 puls is equal to zero, here the falling edge will come later so the ECU will know this is the reference.

But when I measure the signal on a oscilloscoop the zero puls my PCI generates is not in the middle of the signal, when the frequency is 20Hz it's perfect, but when a use a floating point ( a comma number ) the zero puls is not in the middle ( or reference ).

The zero puls should be in the middle of the signal with every frequency! so the ECU will always measure a zero puls after 35 pulses (with every frequency).

How should I solve this problem? The minimum frequency = 14,7Hz ( engine running stationairy ), the maximum frequency = 108,4Hz ( engine running at his highest rpm ).

Thank you very much for every reply,

Stijn

[orko]

The problem appears to be phase related. When the sine wave generation is not reset to zero (this is the default), it starts generating the sine wave at wherever it left off on the last call. Setting a constant of TRUE on the sine wave generator "reset signal" input should rectify your problem.

[Stijn]

I've allready found the perfect VI on an NIforum, see attachment.

The original VI has the controls ( N teeth & -n teeth ) outside the while loop, I've put them in the while loop, is this a problem?

Because now that we've got all the 15 sensors we have to combine them which eachother,

for example :

the camshaft turns half the rpm the crankshaft does, there also is a phase difference between this 2 sensorsignals

how should I best program my application ( I wanna make it an execute file ), the main target is :

* simulate all sensor signals : done

* build them all in 1 .exe with ergonomic frontpanel --> at the moment all sensor are programmed seperated in a while loop so they can be runned and stopped

I've allready thought about a case structure and every case is linked to a tab on the front panel with on the tab and in the case structure label the sensorname

* output the signal with a PCI-6704 (static signals) and a PCI-6229 (dynamic signals) with the DAQ Assistant for data acquisition

Probably we've gonna have problems with this part, because we want to run a application with real-time adjustable output parameters with this PCI's

I don't know if this is gonna work, I've heared I can put a DAQ with different data inputs and outputs, as much as the PCI has outputs

6704 : 16 analog ouputs / 6229 : 4 analog outputs, we only use the analoge voltage outputs to simulate our signal

* make a testpanel with all actuators in a teststand with a PC with PCI's linked to the ECU ( motormanagement ) and this ECU linked to the actuators while the sensors are being simulated with LabVIEW 8.2, so the actuatorsignals ( output of the ECU ) can be checked on correctnes.

Tomorrow we're going to send the signals to the ECU and check how he reacts because we still have to find the exact triggerborder by fine tuning,

I would appreciate some forumhelp with the building of the program because at the moment I do not really know how I should do it best.

I was thinking of making all sensors subVI's and then link them in a sort of way, but i'm not really a big pro yet with LabVIEW it's the first year I work intensive with the program. In may I'm gonna follow Basic Course I & II.

Cheers,

Stijn

[orko]

QUOTE (Stijn @ Apr 15 2008, 12:47 PM)

I've allready found the perfect VI on an NIforum, see attachment.

It is customary (and reduces frustrations) to give a link to and plainly state when you are posting the same question to multiple forums. This is called "cross-posting" and is generally frowned upon.

Example: http://forums.ni.com/ni/board/message?board.id=170&message.id=316381&query.id=173409' target="_blank">Cross Post from NI Forums

That said, I don't have time today to look further into your situation, but there may be others here that will provide some input. Good luck!

[orko]

QUOTE (Stijn @ Apr 15 2008, 12:47 PM)

The original VI has the controls ( N teeth & -n teeth ) outside the while loop, I've put them in the while loop, is this a problem?

Not a problem if you need to control the values while the loop is executing.

QUOTE (Stijn @ Apr 15 2008, 12:47 PM)

how should I best program my application ( I wanna make it an execute file )

Not sure what you're asking here exactly. If you're asking how to build an executable in LabVIEW, then I suggest looking at the internal help available in LabVIEW. Or look online at ni.com.

QUOTE (Stijn @ Apr 15 2008, 12:47 PM)

I've allready thought about a case structure and every case is linked to a tab on the front panel with on the tab and in the case structure label the sensorname

You might want to look in Help->find examples for DAQmx examples. I think there are a few that demonstrate how to aquire multiple channels at the same time.

QUOTE (Stijn @ Apr 15 2008, 12:47 PM)

* output the signal with a PCI-6704 (static signals) and a PCI-6229 (dynamic signals) with the DAQ Assistant for data acquisition

Probably we've gonna have problems with this part, because we want to run a application with

real-time

adjustable output parameters with this

PCI

's

I don't know if this is gonna work, I've heared I can put a DAQ with different data inputs and outputs, as much as the PCI has outputs

When you say "real-time", do you mean deterministic (predictable execution time)? If your application doesn't have to run in a tight loop (within microseconds of the set loop execution time) and will not harm external equipment if it has occasional pauses or lags in execution, then PCI cards will do. If you need tight control however, you will have to go with a more real-time operating system. I would suggest talking to your local NI rep for advice.

QUOTE (Stijn @ Apr 15 2008, 12:47 PM)

In may I'm gonna follow Basic Course I & II.

Excellent! I would suggest the Intermediate courses as well if you can, since that is where I felt I learned the most about how to structure a LabVIEW application. Basics courses showed you the building blocks - Intermediate courses showed you how to put them together.

[Tim_S]

QUOTE (Stijn @ Apr 15 2008, 02:11 PM)

All the sensorsignals has been simulated but now we've got to simulate the crank shaft signal, this is a inductive sensor that stands next to a flywheel, on the flywheel there are 35 theeth and after the 35 theeth there is 1 thooth gone.

I'm half-surprised you're using a passive sensor as most cam/crank sensors I'm seeing are active and output a digitized signal.

Tim

[Stijn]

QUOTE (Tim_S @ Apr 16 2008, 05:02 PM)

I'm half-surprised you're using a passive sensor as most cam/crank sensors I'm seeing are active and output a digitized signal.

Tim

Yes I know, but this is an old motormanagementsystem, it's a Ford EECIV from a Ford Mondeo 2.0 16v Zetec 1993

the only active sensor is the speedsensor, it's a Hall-sensor but the cam and crank sensors are inductive sensors.

Stijn