Hi GerdW,
Thank you.
Actually I had backup once any important progress while coding.
The software is finished in last week. So I deleted all the unfinished backup, and kept one zip backup. This week I I found the main VI was missed and I failed to find it in the zip file.
The midst of sadness, the exe file and all the sub VIs are still there.
Is it possible to converse the exe to VI?
Regards,
TE
The material is the same. But I say the on site is more valuable since you have somebody to ask questions to.
I think I tried before, it wont work
Could you try that for me? Thank you in advance
Build the simple application to get the relay counts and make a simple string report. My suggestion is to have the server be a fixed IP address and have it "listening" for a TCP/IP connection. Then your console applications just attempt to connect, send the data, and close the connection. The server can do whatever it wants with the data from there. But as soon as that connection is closed, it is waiting for another one. You can allow the consoles to retry to the connection for those situations where multiple consoles are trying to connect to the server.
TheWaterbug wrote:But I also need the VIs to be architecturally simple, even at the expense of elegance, so that newbie LV users (like me
) can understand and adapt them.
Then my first recommendation is to make wrapper VIs for all of your function calls. These should be complete with documentation (at least context help), meaningful control labels, meaningful icon, and free labels describing what is happening. Then you can make your simple examples using those wrapper VIs. This will look a lot more professional and guide to understanding.
It worked for me. Boolean 2 blinks superfast when Boolean 1 is on, much slower when Boolean 1 is off.
Try again. If you still have a problem, attach your modified VI.
cstorey wrote:Sorry Jeff, its a bit semantic but SCPI is not IEEE 488.2. One defines the communication protocol and the other the command structure. SCPI can be used on non-488.2 hardware (RS232/488/USB). See..
https://en.wikipedia.org/wiki/IEEE-488
https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments
While IEEE 488.1 defined the hardware and IEEE 488.2 defined the protocol, there was still no standard for instrument-specific commands. Commands to control the same class of instrument, e.g., multimeters, would vary between manufacturers and even models.
The United States Air Force,[4] and later Hewlett-Packard, recognized this problem. In 1989, HP developed their TML language[5] which was the forerunner to Standard Commands for Programmable Instrumentation (SCPI). SCPI was introduced as an industry standard in 1990.[6] SCPI added standard generic commands, and a series of instrument classes with corresponding class-specific commands. SCPI mandated the IEEE 488.2 syntax, but allowed other (non-IEEE 488.1) physical transports.
The Hp8510C did not support IEEE 488.2 or SCPI, but did support 488.1 GPIB and defined its own set of commands.
Don't go there. several instrument mfgs have claimed compliance to IEEE488.1 There is no such thing! 488, 488.2 Other than that mfgs have tried to bamboozle you! 488.1 is like RS-232. Dou you know what the "RS" is short for? (Recommended Standard)
point to a definition of IEEE488-1 (its SCPI wannabe) Then RTM for the 6603B and understand the SYStem:LANGuage command <SCPI|HPPSL>
Some additional notes:
Thanks in advance.
ENG.TE wrote:Is it possible to converse the exe to VI?
Regards,
TE
"Converse"? Not the correct word. I assume you mean to decompile the exe back to a VI. Maybe you meant to say "reverse"?
The answer to that is no.
Thanks!
Hi TE,
The software is finished in last week. So I deleted all the unfinished backup, and kept one zip backup.
So this is all our fault… 
(Using a proper SCC tool you wouldn't be in trouble like you are.)
This week I I found the main VI was missed and I failed to find it in the zip file.
This leads to the question how you organized your projects (and all the VIs belonging to it) on your harddrive! Wouldn't it be easiest to keep them all in a (dedicated) folder and ZIP just that folder?
As you programmed all this and you still are able to have a look at the front panel of the missing VI you surely don't need weeks to recreate that VI!
It's a lesson you learned now the hard way: use a SCC tool!
- Keep backups.
- Backup often and early.
- Store backups in a safe place - outside of your development computer, outside of your office, outside of your office building.
Hi hypfco,
Which is the maximum speed of this module?. In the datasheet the figure "Update Rate" reads 0.5us.
Yes.
This means a clock of 2MHz can be configured for sampling digital inputs at this speed?
Yes.
Can this module lock at a given external (or internal?) clock for synchronous communication as receiver?.
No.
Why don't you use a serial port?
Hi RavensFan,
Yes, I meant decompile. Thanks.
Hi GerdW,
Many thanks for your helps.
I think I can rewrite it within 3days, and now it seems no any other solutions.
I will try to find and use one SCC tools.
Regards,
TE
You could also follow this tutorial to make LabVIEW Plug and Play drivers. You can go here to look at examples to help you out. I think having drivers that follow the LabVIEW Plug and Play standard would be very professional.
I am acquiring interference fringe pattern from VISION using PCI-1405 and able display fringes after selecting ROI . I need to take its line of profile continuously so that I can monitor movement of its peak. I used a typical labview and vision based program which displays those fringes continuously (Copy of vi attached) but not able to get its line profile . I am beginner in this field. I also tried Vision Express and Vision assistance express (vi attached) but here also not able to get line profile of fringe pattern displayed. Please help me how to take line/intensity profile to track peaks.
I think a lot of us here learned this lesson the same way, but probably in a less dramatic fashion.
This proposal worked for my colleague! Thanks for pointing out this option.
In addition to what I wrote earlier, the Debug license is not enough to develop the application. Your contractor would also need to own a full development license with the relevant Toolkits in order to be legal. The debug license is only meant to be used on the final target system for debugging purposes and minor code modifications that result from debugging the software, not for the actual development work.
Unless this is about a turn-key solution where you wouldn't care at all if the solution is written in LabVIEW, Python, assembly or Marsian, I would think it to be more sensible choice to have your contractor own the full development license of LabVIEW for the development work and add a debug license to the cost of the project for your own use. That way the software is tested on your hardware with your debug license and if you ever need to have someone look at the program for debugging purposes after the whole software has been delivered, you can do so without having to jump through hoops and loops first.
When we propose such projects we regularly include a debug license into the quote. The customer may never really use it themselves but it gives them ease of mind to know that they can do it if the need should arrive.
wiebe@CARYA wrote:The DLL stays the same process once it's loaded. So that is why it works. It will probably only work if the VI is set to run in UI thread. I think running in other thread instantiates new instances for each time you use it (not sure might test that).
That doesn't sound quite right. A specific DLL is only mapped once into a process. Unless it uses a SxS (side by side) configuration, only the DLL name is important for Windows to decide if a DLL is already mapped into a process space. With SxS a DLL can be loaded multiple times into the process, once for every version of the DLL that some part of the application links to.
And the Standard C stdio fd's are most likely also C runtime library global but as explained earlier you can easily end up with multiple C runtime libraries linked into the same application. This has also other consequences such as not being able to pass memory pointers allocated in the context of one C runtime library to a context that links to a different C runtime library to deallocate this pointer. Same applies for file descriptors opened with C runtime library functions.
wiebe@CARYA wrote:The DLL stays the same process once it's loaded. So that is why it works. It will probably only work if the VI is set to run in UI thread. I think running in other thread instantiates new instances for each time you use it (not sure might test that).
That doesn't sound quite right. A specific DLL is only mapped once into a process. Unless it uses a SxS (side by side) configuration, only the DLL name is important for Windows to decide if a DLL is already mapped into a process space. With SxS a DLL can be loaded multiple times into the process, once for every version of the DLL that some part of the application links to.
And the Standard C stdio fd's are most likely also C runtime library global but as explained earlier you can easily end up with multiple C runtime libraries linked into the same application. This has also other consequences such as not being able to pass memory pointers allocated in the context of one C runtime library to a context that links to a different C runtime library to deallocate this pointer. Same applies for file descriptors opened with C runtime library functions.