Calorified

Turns out my intuition was right. The discrete KF vi will not accommodate higher-order stochastic state space systems. I confirmed this through the LaVIEW PSC engineers yesterday.

 

If anyone is thinking of a big state space structure as I was, the easy way out might be to build your own KF application.

It's a bit lame but what I ended up doing was to receive the multicast on the Windows Virtual box, create a second ordinary udp broadcast to the RIO and receive the udp broadcast on RIO. Still no noticeable delay. 

 

Someone in my lab told me I could have used a shared variable engine to move the data around from my PC to RIO target. I tried this unsuccessfully with the 'Single-Process Shared Variable' as well as 'NI-PSP Shared Variable'.

 

Maybe if someone has a way out, they could further shed some light on the shared variable host send and target receive.

Hello there,

 

I tried to implement the discrete time Kalman filter in a closed loop estimator scenario based on the "CDEx LQG with Linear Simulation" example located in 

 

             `C:\Program Files (x86)\National Instruments\LabVIEW 2015\examples\Control and Simulation\Control Design\State-Space Synthesis`

 

that ships with LabVIEW. Only difference is my application is a 4 x 4 state matrix.

 

The thing is the kalman filter output, \( y(t)(k|k) \) and output estimate, \( \hat{y}(k|k)\) do not get updated.

My vi.png is here:

 

 

I know it says somewhere on the help pages that the KF vi needs a second-order process components. But does this mean the vi would not work with higher order systems?

 

Would appreciate your input.

I quote from here :

 

• "This will add the static route for all packets arriving from the possible UDP multicast address range (224.0.0.0 through 239.255.255.255). To make the changes persist through rebooting the device, you can either write a script to run this command on device initialization or manually add the rule to the network interface configuration file in /etc/network/interface."

Why do you say it won't work for an address that starts with 235?

You have quite a stack of network virtualisation there.You'll probably have to set up routing to forward  UDP multicast packets from your router.

You meant this: route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 ?

Hi there,

 

I have RIO in a Windows VirtualBox inside a Ubunbtu Host OS.

 

I am sending data from a C++ program in the Ubuntu Host system to labview within the Guest OS.

I can receive the data on labview installed on the windows guest os. Below is the png of the Windows working program.

 

 

But when I tried to send the data to myRIO, I was getting a udp read only error 42.

 

Somewhere on the NI forums, someone suggested the net address of the "UDP Multicast Read-Only" vi  be wired to the address of the RIO which I have done below

 

.

 

Now, the code runs on myRIO but I can't receive any data on RIO. The multicast address I am sending to from Boost Asio C++ is 235.255.0.1 on port 30001.

 

The RIO has a public ip of 172.22.11.2 and I set up a static ip address for it in NI MAX as the address of the UDP Multicast : "235.255.0.1.

 

 

 

At this moment, I do not see what I am missing. All firewalls have been disabled and I have set the permissions for RIO through the Windows security page.

 

Any help would be appreciated.

Thank you!

You mean read the MV variable inside the bottom loop? You seem to be suggesting I should ignore the shift register altogether. Either way, the PV would not update inside the loop as well. Could it be 'cause I'm streaming the PV from a UDP connection? If this is so, what would be the viable alternative to communicating between real time and the fpga mode?

Hi Neil,

 

Have you ever had to stream data to some fpga vi via udp? I am having issues reading a streamed data to RIO on an fpga(pid) express vi. I used a local variable and tried a global variable as well to move the data over to the fpga vi while loop. In the while loop of the udp connection, I can read the data but not in the while loop of the fpga vi. The code itself is running on the RIO and the fact that the probe reads data in the scan engine loop tells me the integrity of the data I am streaming is not the issue. The png file is here. 

Looking forward to your reply.

Hey, I know this is a crosspost as well, but I will be glad to get help either way asap. I have a deadline for tomorrow morning.

 

I am using the FPGA(PID) VI too. I ran into some issues lately.

I am streaming the Process Variable over the internet via a udp connection. My manipulated variable is supposed to be the current that is being varied from the C/AO0 of the RIO FPGA functionality.

Problem is when I run the program and I probe the global variables PV: Kinect Data and MV: Current (mA) in the top while loop, I can read the data. Not so in the PID Processing Loop.

Can anyone tell me what I am missing?

 

It's fixed actuially. It wasn't a firewall issue. It was an IP address conflict issue. Sad thing is it took close to 10 hours to debug this.

Check your Windows firewall. Turn it off completely and see if this fixes it.

Turned off, no luck. 

 

 Turn it off completely and see if this fixes it, if it does then you perhaps need to add the LabVIEW.exe process to the whitelist for UDP.

And this is done in Firewall tool?

I have a UDP connection setup on a Windows 7 machine that runs an IMAQ code. The machine can send and receive udp connection so long as data being sent it is on the same machine. When I send the code from a different process (running on Windows 7), I am able to read the data on the RIO udp receiver VI (running on the Windows Host) as well.

So I changed the sending program to a labview code and the udp receiver won't pick up the data.

Could there be something I am missing?

Attached are the PNG files (lava1 is the talker (same as the Kinect Code VI) while lava2 is the receiver).

Any clues would be appreciated.

Kinect Code.vi

If you take a look at the subvi, where I am queueing data, you would see the FTP vi receives a certain data over a udp connection. I am sending data to this subvi from a different program. Trying to embed the subvi in the top vi works for the first 5 seconds or so and then it stops sensing the udp data. The loops are separated because I want to use the process data in a separate program. What exactly are you suggesting by your question, "What is the motivation for separating the loops"

I am trying to read the value of some data in a while loop from a sub-vi (attached as FTP WPF UDP below) into the top-level vi (attached as Proportional Controller VI) but I find that the data is timing out in my top-level vi whereas it runs smoothly withing the subvi. I have used the while loop and the timing in the subvi is synchronized to the external code that sends data via udp to the subvi. 

Is there a way you think this can be fixed?

Below is my attached code.

Thank you!

 

Proportional Controller.vi

FTB WPF UDP - Original.vi

Fixed.

 

 

Well, I am noticing you are not passing your TDMS File reference from the Open TDMS to the TDMS Write.  The other thing to be aware of is where you put the file.  I recommend giving this article a good read: http://www.ni.com/tutorial/14669/en/

 

 

Well, I am noticing you are not passing your TDMS File reference from the Open TDMS to the TDMS Write.  

Well, I made the change and still got no way around this.

 

 

The other thing to be aware of is where you put the file.  I recommend giving this article a good read: http://www.ni.com/tutorial/14669/en/

What exactly do you mean? I tried the home directory and the broken links are still there.

 

RT Current Control.vi

Hi all,

 

I am trying to log files to some tdms file in myRIO. I got the code setup in myRIO FPGA side and the RT vi (both attached below). I have the Real TIme code working but I can't seem to get the data-logging VI working (it tells me I have a lot of broken wires and methods not supported in target). Please take a look at the RT Current Control.vi code and see if there is something I am missing.

Thank you!

RT Current Control.vi

Current Control.vi

I have fixed this. Here is my updated circuit design and the DAC control diagram

I am trying to drive a proportional solenoid valve: PVQ-33-5G-23-01N ( which responds to currents between 100mAand 165mA. I am using a circuit similar to the one in the attachment below except that I am using the myRIO's DAC in place of the AD5446, the LM324(http://www.ti.com/lit/ds/symlink/lm124-n.pdf) in place of the OP1177 and the MOSFET(http://www.mouser.com/Search/ProductDetail.aspx?R=VN3205N3-Gvirtualkey68900000virtualkey689-VN3205N3-G)[/url]

So the challenge I am having is how to configure the circuit in labview. I am trying to use the default FPGA person ality of myRIO. I am supposed to generate a 1.2V Vref signal into the pin 3 of the LM324. By varying the word that is sent to the LM324, I am supposed to effectively vary the current on the Drain terminal of the mosfet. I have wired the Vref terminal to Connector C/AO0 on the myRIO and I have the VI below but I have no experience sending bits and bytes. I would love to drive the solenoid with about 10 -15 steps of current. Any help would be appreciated.

Hey y'all. Code is fixed. I am brilliant now

I'm posting the .png file in case someone in the future runs into same issue.

Right-click the Numeric constant inside the array constant (which is wire to the Type input), choose Representation -> SGL (Single-Precision).

So I have the array constant but but in LabVIEW 2014, I can't find my way into Choose Representation. or SGL.

You could also wire a numeric constant without the array, since your code sends only one value at a time.

Now, I tried this and I am having floating point numbers as my output. But I notice my data is of the order 1.06607E+9 when in actual fact, it should somewhat be 1.06607.

Am I missing something?

Thanks. How do you change the type on the Unflatten String into Array of Single Precision?, I wired a numeric constant to it and typed 0.00f into it to indicate float and then ran the labview code but I got an "error 74 occurred at Unflatten From String in "Code UDP"

I tried this before but I will try again. What do you suggest I wire to the type terminal on the Unflatten string?

Here's what I am sending from the C# end. It's binary.

this.facePoints3D = frame.Get3DShape();

// UDP Connection :: Talker ::

Boolean done = false;

Boolean exception_thrown = false;

Socket sending_socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);

IPAddress send_to_address = IPAddress.Parse("172.22.11.2");

IPEndPoint sending_end_point = new IPEndPoint(send_to_address, 80);

while (!done)

{

foreach (Vector3DF vector in facePoints3D)

{

//arrange

float zvect = vector.Z;

byte[] bytearray = BitConverter.GetBytes(zvect);

Console.WriteLine("sending to address: {0} port: {1}",

sending_end_point.Address,

sending_end_point.Port);

try

{

sending_socket.SendTo(bytearray, sending_end_point);

}

catch (Exception send_exception)

{

exception_thrown = true;

Console.WriteLine(" Exception {0}", send_exception.Message);

}

if (exception_thrown == false)

{

Console.WriteLine("Message has been sent to the broadcast address");

}

else

{

exception_thrown = false;

Console.WriteLine("The exception indicates the message was not sent.");

}

} //ends foreach statement

} //ends while(!done) statement

I am getting something of this sort from the UDP Read function in labview when I wired an indicator to it: ƒª’?

After unflatteneing, I am getting values which are inherently not corresponding (e.g. numbers like 141, 168, 200) to what I have on my console window (floats such as 1.8543, 1.115 etc).

Let me know what you think.

Really? Do you mind sharing the Delphi Code as well as the Labview VI?