From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Rotary encoder and pressure sensor sync

Good ay, I am looking for some help getting my script functioning within expectations. The script collects data from a single-cylinder engine and is meant to synchronize cylinder pressure against crank angle. 

The in-cylinder pressure is being measured by a combustion pressure sensor run through a kistler5073 charge amplifier which I am reading using a 9215 analog voltage read module. 

The crank angle is being measured by a rotary encoder attached to the output shaft of the motor and is measured by a 9361 rotary encoder read module. 

There are a few thermocouples in the script meant to capture the intake, block, and exhaust temperature with a 9211 module but they are largely not important. 

There is a third section that pulls data from a web-enabled gas analyzer that is working as expected.

I am currently having two main issues with the program:

1) When cranking the engine without running the peak compression should be happening at around 0 degrees as that is top dead center, the script displays it as 250 degrees for some reason, could this be caused by latency or is there another underlying issue that I am missing?

2) Over the course of a few minutes, the bottom range of the pressure sensor slowly crawls up so that instead of reading ~0 Bar it is reading closer to 10-15 Bar. Is there a chance that this is caused by something in my script or is it more of a manufacturer issue and I need to take it up with them?

 

I have attached my VI so you can properly see my configuration.

I am also very open to any efficiency changes and best practise, I am very green when it comes to Labview but I have hit the limit of what I can find resources that seem to apply to my situation and I am looking for someone smarter than myself that can point out the things I have gotten wrong.

I did add the file naming script inside the loop on purpose so that it creates a new file every minute so that the file size stays manageable and my underpowered laptop can open them after testing without crashing. 

 

Thanks in advance.

0 Kudos
Message 1 of 13
(2,459 Views)

I'm going to keep looking regarding the two questions you listed, but some observations regarding the VI

  • Actually, the system doesn't seem too bad. However, the VI is much too large to easily read. You need to use some subVIs (even for a forum post, just zip up a project file with VIs included and then tell us to open for example "Main.vi" in the project
  • You're using a 2D Array of DBLs as your transport element, but it seems like a cluster of arrays of DBLs, and scalar DBLs, might fit your needs better. Then you can use Bundle (by name) and unbundle rather than a dynamic data type.
  • Lots of your wires are tangled/not straight (some bends are generally unavoidable, but you could clean a lot of yours up for this VI)
  • TDMS will allow you to write attributes too, but if you like DDT and xlsx that's fine. I expect there's some way to clean up the Set Dynamic Data Attributes section, but I've never used those nodes or the DDT because it confuses me 😉
  • You might get some merit from structures like the following:

breakout_BD.png

Here I use a For loop and put the constant values in the loop whilst passing in the changing values using an array of clustered values. You could make this a typedef, you could use Unbundle by Name to make it clearer to read (vs more compact), etc.

 

Regarding 1. I think you might just have the rotary encoder offset relative to the position you want to call zero. You're using a Z reset and that has a fixed location in the rotary encoder. Probably it can be rotated relative to the engine and that will change the location of the peak.

2. I don't see a reason for the second issue in the code. Perhaps it's related to the sensor. I'd only suspect the Max+Min node in combination with the DDT (again, I don't know what's going on with DDT wires, they can hide any number of things)  - how are you determining that the "bottom range" is "rising"?

 

 


GCentral
Message 2 of 13
(2,454 Views)

I believe charge amplifiers will drift and need to be reset.

 

Re: 250 degrees

 

Are you sure you have the encoder set-up to read 0 at TDC?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 13
(2,437 Views)

I understand that they drift, but usually over a longer period of time, I cannot even get the engine up to speed and stable before the range is out of calibration again.

 

I am using the Z index of my rotary encoder to reset the angle to 0 degrees exactly at TDC.

0 Kudos
Message 4 of 13
(2,434 Views)

The bottom range of the sensor rising can be seen both in the raw data, and the plots of the data as well.

 

The max/min node, is display only to make it easy to check peak while the test is happening but is not generally being used as the final word.

 

Currently the Z index when rotated by hand and checking the output is less than a degree from TDC, it was a source of error early on but was one of the first things I corrected when I got onto this project. 

 

I was writing to TDMS but my computer was having issues opening the files previously but will likely be what we end up using, either that or LVM to make it easier to combine the data into a continuous stream.

 

I will definitely look into the cluster handling of the data, as previously stated, I am super new at this and the dynamic data handling is a transfer from the express VI's and seemed like a reasonable way of handling things, but I would be glad to be rid of the conversions.

 

The data structure looks very interesting, I will take a look at that as it is definitely easier to read than the relative rats nest of wires I have going on. The automatic wire cleanup makes them cleaner but really messed with the logical progression of how the data moves from area to area in my mind. Definitely need to clean up more and I apologize for having a hard to follow VI, it can be easy to forget that the people looking won't have the same thought process as the person who built it.

0 Kudos
Message 5 of 13
(2,423 Views)

The automatic cleanup can be useful, but mostly for small VIs. You can also select specific parts of a diagram and only tidy those (or right click on loops and structures to exclude them).

 

I have heard it said that the shortcut for block diagram cleanup is Ctrl-u Ctrl-z though... 😉

 

Glad to know Z index is in the right location although don't currently have a second hypothesis for why it might be reading at 250 degrees...

 

Sounds like the sensor might have something to do with your pressure drift. 


GCentral
0 Kudos
Message 6 of 13
(2,414 Views)

You didn't *quite* sync your encoder and AI tasks & data.  You did 2 out of 3 things right though.

 

1. Run all tasks from a shared sample clock.  You did this by configuring the encoder task to do sampling using the AI sample clock.

 

2. Make sure the "master" task is started *LAST*.  Here, it's the AI task because the encoder task depends on it for the sample clock signal.   You did NOT do this.  You need to add some sequencing to make sure the encoder task starts first and the AI task starts last.

 

3. Read the same # samples from both tasks.  You're doing this. 

 

Unfortunately, it appears that the AI task happens to start first.  Many AI samples get buffered before the encoder task starts buffering values.  So when you *correlate* the 1st sample in their respective buffers, those samples aren't actually in sync with respect to *time*.  That explains the offset you see.  I'll bet that if you run several times, the offset will vary some.

 

If you make sure the encoder tasks start first and the AI task starts last, you'll start seeing correct correlation and consistent behavior over multiple runs.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 7 of 13
(2,410 Views)

@cbutcher wrote:

The automatic cleanup can be useful, but mostly for small VIs. You can also select specific parts of a diagram and only tidy those (or right click on loops and structures to exclude them).

 

I have heard it said that the shortcut for block diagram cleanup is Ctrl-u Ctrl-z though... 😉

 

Glad to know Z index is in the right location although don't currently have a second hypothesis for why it might be reading at 250 degrees...

 

Sounds like the sensor might have something to do with your pressure drift. 


Depending on the RPMs a low pass filter could introduce a phase shift.

 

But I suspect the DAQ Champion Kevin is probably onto the real answer.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 13
(2,403 Views)

So to start my AI task last would I just put the start task items in a flat sequence before my loop with the encoder first and the analog sensors last? 

0 Kudos
Message 9 of 13
(2,393 Views)

Or move the error wires up and down. Perhaps using Merge Errors. 

 

Edit: thats perhaps a little unclear. I mean that you could take the error out from your start on the counter task and connect it (optionally using Merge Errors) to the error in of the start for the AI task.

 

As a follow-up question, can the AI tasks be grouped (temp and pressure)?


GCentral
0 Kudos
Message 10 of 13
(2,391 Views)