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.
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.
04-04-2016 07:23 AM
i have developed a desktop to be a LabVIEW real time target, and i have a code implemented on a host target as a blank VI that i would like to run it on this real time pc target. the idea about the code is as follows, i read data from an excel sheet that have two signals saved in as points, i normalize these two signals and remove the mean and then i cross correlate the first 500 points from this excel sheet with the streaming of the whole number of points in the same excel sheet in order to determine the shift that happened between the fist 500 points and the rest of the points , i have problems dealing with the target configuration on how to read and write this code and actually run it on the real time remote system target pc from my development pc . kindly find attached the blank VI code that i want to run in a Real Time project where the real time target is configured as a remote system in MAX and the project with this remote system configured in. i cann't attach the tab delimited file path the input for the code as its too large.
04-04-2016 08:00 AM
If the file is too large to attach, then it probably is too large to load into memory all at once. Is it possible to read the file one line at a time, instead of working with the whole file at once? The Read Text File can be configured to read one line at a time by right clicking and choosing Read Lines.
You said you have a problem reading and writing this file but never said what that problem is so I'm just guessing.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
04-04-2016 08:20 AM
How large is the text file?
Ben
04-04-2016 12:36 PM
I'm not sure why you are talking about a Real-Time Target -- it sounds like the task you want to do is "ordinary LabVIEW", namely reading data from an Excel Workbook and doing specific computations with subsets of the Excel data.
Why is this "Real-Time"? Is the idea that you want a Remote PC do help by doing some of the computations for you, and communicate with the Host PC via Network Streams or some other TCP/IP protocol?
Several questions. Can the LabVIEW code that you want the Remote to execute also be run on the Host (with no "Real-Time" specialization)? Can you build an Executable that can run the code?
If no real "Real-Time" is involved, you can still use the other PC to help you out (I think). Consider writing an Executable that "pretends" it is an RT System by trying to establish a Network Connection with the Host. Once the connection is established, the Remote does whatever you tell it to do and communicates back with you.
What differs here is Deployment and how you use (or abuse) LabVIEW Project. If you are just building an Executable, you Deploy it via USB key or by Mapping a Network Drive to the Remote machine and copying it. To run it, use Remote Desktop and simply reach out and double-click its Icon on the Remote Desktop (you can then close the connection).
Bob Schor
04-04-2016 12:59 PM
it contains nearly 500,000 points but as you can see in the blank vi code i make the loop stop when it reaches 10000 points just for now to make sure that the concept is correct
04-04-2016 01:02 PM
yes that was one of the problems, the thing is i am not familiar with how to configure the attached blank vi code to be executed in the real time target project for the remote system to execute the code and then i see the output on my development computer. thank you for your help.
04-04-2016 01:07 PM
yes exactaly, i want the to configure this blank vi code to be executed in the real time target for the remote system to help me with the computaion and timing and i know the work around you just said but yes you are correct its a normal labview code that i want it to be as a real time target ; its something has to do with the experment i am conducting so i can then use a data of 50k or 100k from the laser. thank you for your help.
04-04-2016 01:14 PM
Is the "attached blank VI code" to which you refer the "ReadDataFile" VI attached to your first Post? There's nothing in there that requires LabVIEW RealTime. Again, what are you trying to do? If you intend to hand off computations to another PC running a "Compute things for me" routine, then there are some important questions to be answered:
Bob Schor
04-04-2016 01:49 PM
04-04-2016 04:19 PM
@MoroAfifi wrote:
Yes, by the blank VI code i mean the ReadDataFile VI, i want to change this code from the normal labview format to the Real Time configuration format in order for me to be able to run it on the Remote Real time target i developed using labview realtime software ( imagine it as if i am trying to run this code on any target as DAQ, myRio.. Etc but in my case i want to run it on the RealTime desktop pc from another host(development) pc to make the core serve nothing but to run this code)
1- The remote system runs all time through max as long as iam connecting between the two PCs with the ethernet cable
2- i am planing to run this code on the realtime target for me to be able in the future to use a higher frequency data from the laser which is my input but i don't actually have the laser but i have several data saved in excel sheets 100hz , 50Khz .. Etc .
3- the main development pc in my case the host , the other real time pc target has nothing but the realtime software I developed by booting it from a usb utility.
4- the inputs for the remote pc( the pc with the real time software) and the outputs are the same as in the ReadDataFile , the spreedsheet as input and the shift detected is the output
5- the basic reason is to make the core for the realtime desktop pc serve nothing but to run this code in order for me to reach high frequency laser inputs in the future.
OK. I'll confess that I've not done LabVIEW RT with a PC as the Remote, so what I say comes from my experience with more "usual" Remotes, including RIOs and PXI systems (with Intel "PCs" inside).
I'm sure you realize that the RT "model" implies that the Target (a) runs all the time, (b) boots up and runs a single "start-up" routine, and (c) has very limited user interaction except through communication with the Host. In addition, I'm not aware that, say, a PC running "ordinary LabVIEW code" on a Real-Time OS has any significant (vague term, that) speed advantage over, say, a Windows 7 PC running the same code.
Given the option, it would seem not unreasonable to have a PC that ran Windows and could, if needed, be dedicated to, at specified times, run a single easily-selectable program that "did one thing", namely served as a "slave" for another PC by doing laborious calculations and returning results. When the machine was not so engaged, it would be used as a "regular Windows PC", say for e-mail, Web Browsing, Writing the Documentation, etc.
Some comments to your points, above.
I think I already covered Points 4 and 5.
I'm not sure how you were planning to program the Remote machine, but it seems to me that any code that you develop as an RTEXE can also be developed as an EXE. You would "deploy" it either by USB (copying it to a folder on C:\Program Files, for example) or by simply writing it to RemotePC\\C$\Program Files\My Remote App. To start it, you would bring up Remote Desktop and simply run it. Note that with this model, you could have a dozen applications sitting on the Remote, ready to run. On the other hand, to switch RTEXE's on a LabVIEW RT System, you have to connect and change the Startup Application, then reboot the Target to get it to switch. [I know -- dealing with a "locked-in" RTEXE was one of the "flaws", in my mind, to the new RTEXE/RTOS model. I got around it by writing a utility, an EXE, that lets me change which of several RTEXEs on the Remote will be the Startup code].
Anyway, good luck with your Project. If you have experience writing LabVIEW RT Projects, I'm sure you'll have no problems with getting your two routines to talk with each other, whether you do this with RTEXE/LabVIEW RT or EXE/Windows.
Bob Schor