Dyno software integration

[samgm2]

I am writing control software for a dyno that we have just installed. The problem is that most dynos are really just designed to do wide open throttle tuning and frankly pathetic software and electronics support.

I have written software to control the dyno using a Labjack U6 PRO DAQ. This amazing unit is both low cost and very robust.

Now I could produce an analog representation of torque from the dyno load cell that would feed into one of the A/D channels of the EFILive V2 scanner, but then I would have to export the runs for later processing. Ideally however, the processing could be performed live if I was able to access the current injector duty cycle being scanned by the V2 and feed THAT into MY program for real-time calculation.

What I am after is the derivation of a spark table based on an efficiency calculation.

I would like to be able to access an efilive DLL that I can query for the "current fuel injector" duty cycle and RPM if possible (spark would be varied to find the efficiency maxima). Even better would be a dll function that can advance or retard timing through an efilive DLL for completely automated spark table derivation.

I would be surprised if such a dll didn't already exist (as part of the internals of the scanner software). Is there anyway that a few of the functions within the DLL could be made available? It would make dyno tuning far more robust and frankly produce near perfect tuning results. Spark tuning is far too much of a guessing game. This would eliminate that (as long as a dyno with the proper hardware signals is available).

Does such a dll already exist? Is it already available or can it be made to be.
Thanks,

I am hoping that a ".NET" accessible dll is available.

Sam

[joecar]

...

Now I could produce an analog representation of torque from the dyno load cell that would feed into one of the A/D channels of the EFILive V2 scanner, but then I would have to export the runs for later processing. Ideally however, the processing could be performed live if I was able to access the current injector duty cycle being scanned by the V2 and feed THAT into MY program for real-time calculation.

What I am after is the derivation of a spark table based on an efficiency calculation.

I would like to be able to access an efilive DLL that I can query for the "current fuel injector" duty cycle and RPM if possible (spark would be varied to find the efficiency maxima). Even better would be a dll function that can advance or retard timing through an efilive DLL for completely automated spark table derivation.

...

I'm interested in how you use injector duty cycle and spark advance in your calculation, and how this effects the tuning process.

There already are some dyno integration pids available in the software.

[GMPX]

Same, there is a pdf in the EFILive V8 Docs folder called "EFILive Flashscan Serial Protocol", this can be used to share Scantool data with the Dyno. There is a number of dyno companies who have implemented this.

[minytrker]

Same, there is a pdf in the EFILive V8 Docs folder called "EFILive Flashscan Serial Protocol", this can be used to share Scantool data with the Dyno. There is a number of dyno companies who have implemented this.

is dynojet supported?

[samgm2]

This is certainly a step in the right direction and I will go ahead and implement an interface to the dyno software, but the frame rate is very low with rs-232 and it requires an rs-232 interface. More and more RS-232 ports are getting harder and harder to come by on a laptop. Yes, there are USB to rs-232 adapters out there, but my success with them is very low, especially under Windows 7.

Is there a reason that a limited subset of access to USB data stream can't be provided? Yes, I can interface to the RS-232 data stream but it's long term utility is highly uncertain. At 10 packets per second, the data rate is pretty bad. Any chance that at the very least a baud rate higher than 57K baud can be selected and a packet rate faster than 10 per second forced if the number of pids is low?

Sam

Same, there is a pdf in the EFILive V8 Docs folder called "EFILive Flashscan Serial Protocol", this can be used to share Scantool data with the Dyno. There is a number of dyno companies who have implemented this.

[samgm2]

This interface doesn't depend on the dyno used. It only requires polling the RS-232 port on the scan tool to access the data. You can send a "D" frame to get a list of the current PIDs being scanned.

If you are able to write software to control your dyno then you can also write software to get the data from the scan tool directly. My only problem is the data rate from the RS-232 (which is very low at 10 packets per second) and the fact that it is RS-232 at all.

Ideally, the interface would be through a dll that is privy to the usb data stream (which is several orders of magnitude faster). A limited interface through that dll would make the system far more robust and responsive (not to mention easier than dealing with a serial bus). My suspicion is that a DLL already exists. I imagine that many of us would want access to the data so that we can write our own custom applications (particularly for more sophisticated tuning techniques).

In the mean time, I will go ahead and scan the serial stream. It is certainly better than nothing. It would be nice to be able to program the desired PIDs directly over the serial port.

Paul if you are reading this, a way of changing timing on the fly would be EXTREMELY handy and efficient for tuning on a dyno. Maybe we can call it a "T" frame... :-)

Sam

is dynojet supported?

[samgm2]

Power produced per fuel used will vary based on spark timing. Optimal spark occurs when power produced is maximized as spark timing is varied.

Sam

[Blacky]

Paul if you are reading this, a way of changing timing on the fly would be EXTREMELY handy and efficient for tuning on a dyno. Maybe we can call it a "T" frame... :-)Sam

Bidirectional controls (such as changing timing and fueling) are planned for the RS232 link.
Regards
Paul

[Blacky]

This is certainly a step in the right direction and I will go ahead and implement an interface to the dyno software, but the frame rate is very low with rs-232 and it requires an rs-232 interface. More and more RS-232 ports are getting harder and harder to come by on a laptop. Yes, there are USB to rs-232 adapters out there, but my success with them is very low, especially under Windows 7.

Is there a reason that a limited subset of access to USB data stream can't be provided? Yes, I can interface to the RS-232 data stream but it's long term utility is highly uncertain. At 10 packets per second, the data rate is pretty bad. Any chance that at the very least a baud rate higher than 57K baud can be selected and a packet rate faster than 10 per second forced if the number of pids is low?

Sam

FlashScan's RS232 interface is designed for use with:

• dedicated Dyno Control computers (usually desktop based PCs with real UART ports)
• wide band controllers
• other embedded systems

Most of those devices that are intended for use with the RS232 data stream only have RS232 available, they do not have access to USB.

We may support a high speed CAN based PID interface in future.

If your programming skills extend to handling memory mapped files and semaphores, you could hook directly into EFILive's Scan/Tune interface. Then you can grab the PID data directly from the Scan Tool's memory image as often as you like.
Let me know if you're interested in implementing something like that and I'll send you the specifications.

Just for your info, here's the shared memory layout (Delphi code) for getting PID data from the Scan Tool

  PARM_LEN =                 32;
  UNITS_LEN =                32;
  MAX_SHMEM_FRAMES =        100; // Maximum number of frames in shared memory

  TShmemParm = record
    Name: array[0..PARM_LEN-1] of char;
    value: double;
    units: array[0..UNITS_LEN-1] of char;
  end;
  TShmemFrame = record
    pidCount: integer;
    age: integer;
    notes: Cardinal;
    parm: array[0..MAX_PIDS-1] of TShmemParm;
  end;
  TShmemArray = record
    vinScan: array[0..17] of char;
    vinDirty: boolean;
    pidListDirty: boolean;
    cnxTune: boolean;
    cnxScan: boolean;
    newData: boolean;
    newRealtime: boolean;
    dirty: boolean;
    firstFrame: integer;
    frameCount: integer;
    frame: array[0..MAX_SHMEM_FRAMES-1] of TShmemFrame;
  end;

If in the Scan Tool, you're scanning real-time data then only frame[0] contains valid data and frameCount will be 1.
If you're viewing previously recorded data, then frames[0..99] contain the first 100 frames of selected data and frameCount will be the MIN(100,number of frames selected by user).

Note:
Cardinal is a 'C' unsigned long
boolean is a 'C' unsigned char
integer is a 'C' int
double is a 'C' double
char is a 'C' char
record is a 'C' struct
array[0..x-1] is a 'C' array[x]

Regards
Paul

[samgm2]

Perfect! I would very much appreciate this. I have extensive programming experience.

Thanks,

Sam

FlashScan's RS232 interface is designed for use with:

• dedicated Dyno Control computers (usually desktop based PCs with real UART ports)
• wide band controllers
• other embedded systems

Most of those devices that are intended for use with the RS232 data stream only have RS232 available, they do not have access to USB.

We may support a high speed CAN based PID interface in future.

If your programming skills extend to handling memory mapped files and semaphores, you could hook directly into EFILive's Scan/Tune interface. Then you can grab the PID data directly from the Scan Tool's memory image as often as you like.
Let me know if you're interested in implementing something like that and I'll send you the specifications.

Just for your info, here's the shared memory layout (Delphi code) for getting PID data from the Scan Tool

  PARM_LEN =                 32;
  UNITS_LEN =                32;
  MAX_SHMEM_FRAMES =        100; // Maximum number of frames in shared memory

  TShmemParm = record
    Name: array[0..PARM_LEN-1] of char;
    value: double;
    units: array[0..UNITS_LEN-1] of char;
  end;
  TShmemFrame = record
    pidCount: integer;
    age: integer;
    notes: Cardinal;
    parm: array[0..MAX_PIDS-1] of TShmemParm;
  end;
  TShmemArray = record
    vinScan: array[0..17] of char;
    vinDirty: boolean;
    pidListDirty: boolean;
    cnxTune: boolean;
    cnxScan: boolean;
    newData: boolean;
    newRealtime: boolean;
    dirty: boolean;
    firstFrame: integer;
    frameCount: integer;
    frame: array[0..MAX_SHMEM_FRAMES-1] of TShmemFrame;
  end;

If in the Scan Tool, you're scanning real-time data then only frame[0] contains valid data and frameCount will be 1.
If you're viewing previously recorded data, then frames[0..99] contain the first 100 frames of selected data and frameCount will be the MIN(100,number of frames selected by user).

Note:
Cardinal is a 'C' unsigned long
boolean is a 'C' unsigned char
integer is a 'C' int
double is a 'C' double
char is a 'C' char
record is a 'C' struct
array[0..x-1] is a 'C' array[x]

Regards
Paul