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

If you are referring to the voltage, then yes. 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.

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:

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: 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) 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

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

Can you explain that a bit more?

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