atokad

Figured it out. Turns out when my devices aren't all plugged in and powered on the voltages float across to whatever is open  

3 minutes ago, infinitenothing said:

I assume you've configured the 9205 for single ended vs differential correctly?

3 minutes ago, infinitenothing said:

Are you within the current spec of the 9264?

If you are referring to the voltage, then yes.

3 minutes ago, infinitenothing said:

How are you connecting the modules? A cable or one of NI's breakout boards?

Try and simplify things as much as possible. For example, use a battery as a voltage source directly to the input and disconnect the outputs to rule out loading issues.

The modules are placed directly in the cRIO-9035's slots

Alright I plugged in a DC power supply to a random slot and sent 1.5 volts (McKenna_Air_V_in)

But as you can see the voltage inputs from the other two readings are showing that the voltage on the NI 9205 is floating even though I have the common ground connected tot the power supplies ground.

My NI-9264 voltage is outputting incorrectly, and I am not sure what the issue is.

Here is what I am sending to the FPGA vi:

The top circled number is the velocity of a mass flow controller that operates from 0-5V with a velocity range of 0-75 SCCM. Hence my conversion from actual velocity to voltage is to divide linearly by 15:

Multimeter reading (Idk why it is side ways I cannot seem to rotate it)

We are using a ribbon wire to connect the module to the Sierra Smart Trak C100 MFC so I'm not sure if that is the issue or if there is something else wrong

I am using a cRIO-9035 with the following FPGA.vi:

Mod 2: NI 9264

Mod 3: NI 9205

Mod 4: NI 9213

With this code I am able to get a voltage output from the NI-9264, but when I try to send a known voltage to the NI 9205 my readings are oscillating and completely incorrect. 

On 6/30/2018 at 3:19 AM, ShaunR said:

I think you will find your current VI will be insufficient for what you are trying to achieve

Okay since that's the case I am working on a different method, by trying to combine the two examples of a low-level grab, and a low-level sequence.

I'm trying to do it with a case structure to determine if the images need to be captured or not, it's kind of rough, but the general idea is here. Would this be a better method for what I'm trying to accomplish?

True case:

False case:

Currently it is without the JSON formatting/TCP send, but that can be added once I get the acquisition correct.

Current code as a Producer/Consumer:

18 hours ago, ShaunR said:

Take a look at the producer/consumer. There is a project template when you create a "new" project.

Which one would be better for my project figure one or figure two?

I guess what I'm asking, is what would be the best way to implement the Producer/Consumer pattern with my current VI. Should I be constantly queuing the images in the producer loop? Also, would my dequeue element be placed inside or outside of my for loop in the consumer loop?

Now I am running into the issue of duplicate images being stored, any suggestions on how to get rid of my race conditions?

I think the two main issues are:

1. The loops are being ran at different time intervals, which causes the images to not be captured at the correct times (see: time intervals array)
2. The local variables might not be fast enough to keep up with how quickly the images are being captured

There may be some other issues, but those are the only ones I can think of. How would I go about solving/minimizingthese problems

56 minutes ago, ShaunR said:

At a very simple level just add a

conn.send('ACK')

after

print('File has been saved.')

in your Python code. Then in your LabVIEW code insert a Read.vi before the close.

Oh I get it! Sending a string back ensures all bytes are written to Python before closing the server 

4 hours ago, ShaunR said:

Yeah. It's not ideal since it depends on how much data is being sent. A more robust method is to send an ACK back so that a read function (before close) blocks until all bytes have been received.

Can you explain that a bit more?

1 hour ago, ShaunR said:

Add a delay between the last write and close and make sure you are not terminating (closing) the connection before all bytes have been transmitted.

I added a 4.5 second delay, and that solved my issue!! Thank you so much I've been struggling with this for the last two days

Even when I change that I am still getting the same output.

Would I need a termination character if I am sending the byte size though? Shouldn't the data_len determine how much data needs to be written

I'm trying to send images from a camera connected to my cRIO to a Python script running on my computer. I'm storing the image data in a JSON format, and all of the data is being written correctly, but when I go to send it through the TCP functions, my JSON is getting cut-off about a third of the way through. Here is what the LabVIEW code looks like:

and my Python script:

import socket

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('', 3363))
server.listen(3)

while True:
    conn, addr = server.accept()
    cmnd = conn.recv(4)  # The default size of the command packet is 4 bytes
    print(cmnd)
    if 'CAPT' in str(cmnd):
        # Do the initialization action
        filename = input('Enter the file name: ' )
        filename = filename + '.json'
        with open(filename, 'wb') as f:  # open in binary mode
            data_len = int.from_bytes(conn.recv(4), 'big')  # find out how much data is waiting
            f.write(conn.recv(data_len))  # collect that much data
            f.close()
            print('File has been saved.')

server.close()

I think the error is coming from having to flatten the image to a string and then having it converted to bytes during the transmission control protocol, but I'm not sure how to fix that or work around the issue

output.json