LabView and System Colors

Hi everyone
I am currently developing some small application in LabView 8.0.1. Until now, I've always used the default colors. I usually develop either in MFC (C++) oder .NET (C#). I am completely used to the standard color scheme of Windows - that light grey.
I want to achieve, that my applications look like they were coded in some of the other languages. LabView usually gives me quite a dark grey, which is ... not exactely beautiful and doesn't fit to all the other applications (it's darker).
Is there some way, I can make my application look like some C# Application? Do I have to set the colors manually or can I tell LabView to use Windows' colors.
Thanks, for your help.
Thomas Linder

Somnatic wrote:
Concerning playing around: Why should someone do this. If they mess it up, they need to call us, which means money. You can almost mis-use any application if you're just willing to, so I don't see why I should pay extra care to that.
The thing is that they might not mess "it" up, but something seemingly unrelated like the system colors or fonts, which might be hard to troubleshoot. I agree that normally users don't play around with this, but you should hope not to run into this in a case where they do. Anyway, as long as you're using only standard dialog controls, colors and fonts you should be alright.
As for the dialog, LV has its own dialog because of its multi platform support and the need to be able to provide the same functionality and configurability in all platforms. You can make a call to a windows API function to get this dialog, as shown in the attached.
Note - you can easily get more functionality out of this (look at the link), but I did not write this, and I haven't had use for it yet, I haven't modified it.
Try to take over the world!
Attachments:
Browse_Folders.vi ‏25 KB

Similar Messages

How to determine the system color and set them for my app?

Hi,
I'd like to set the colors of my application to the system's colors. Especially the backgrounds of my JPanels, JButtons and so on should look like in the operating system. If you change the systems color scheme, my application looks really wierd with it's grey canvas an components and the border and menu of the window is displayed in the system's colors.
any idea??
koem

The UIManager only seems to have control over
awt-controls. All swing controls are not listed, when
you try this:
UIDefaults defaults =
UIManager.getLookAndFeelDefaults();
for(Iterator i = defaults.keySet().iterator();
ator(); i.hasNext();)
String name = (String)i.next();
System.out.println(name);
}It would be nice to have it set globally somewhere in
the program.
koemActually, the truth is quite the opposite, the UIManager only has control over swing components.
There are many ways you can set these globally. You can sublcass your own look and feel, use the system look and feel, call UIDefaults.put() etc.
Graeme

Please help me with my electrical engineering homework : temperature control and watering system for greenhouse using labview and arduino

temperature control and watering system for greenhouse using labview and arduino
spesification :
1. max temp : 28 celcius (when temperature is more than 28 celcius, fan ON)
2. min temp : 20 celcius (when temperature is under 20 celcius, heater ON)
3. watering system : aquaponic (grow plant and fish in separate tank but connect each other). Plant roots help filter water for fish. Fish poop for plants fertilizer. So I need a pump to distribute water.
Please help me create VI file simulation.. I'm sorry I'm not fluent in English. May God bless you all
Attachments:
YOOOSHH.vi ‏88 KB

Duplicate thread. Please keep the discussion in that thread where you already have a response. It is also the more appropriate thread for your question.
Lynn

Xilinx SDAccel and NI LabVIEW Communications System Design Suite win a pair of EETimes/EDN ACE Ultimate Product Awards

Last night, EETimes and EDN presented a number of ACE Awards including twelve “Ultimate Product” awards. The Xilinx SDAccel Development Environment for C, C++, and OpenCL won the Ultimate Product Award in the Development Kits category.
EETimes/EDN 2015 ACE Awards
From the SDAccel entry form:
“The SDAccel development environment for OpenCL, C, and C++, enables up to 25X better performance/watt for data center application acceleration leveraging FPGAs and combines the industry’s first architecturally optimizing compiler supporting any combination of OpenCL, C, and C++ kernels, along with libraries, development boards, and the first complete CPU/GPU-like development and run-time experience for FPGAs. SDAccel streamlines the development and deployment of critical algorithms such as Deep Neural Networks used in machine learning.
SDAccel includes the industry’s first architecturally optimizing compiler that makes efficient use of on-chip FPGA resources along with a familiar software-development flow based on an Eclipse integrated design environment (IDE) for code development, profiling and debugging, providing a CPU/GPU-like work environment.
SDAccel leverages Xilinx’s dynamically reconfigurable technology to enable accelerator kernels optimized for different applications to be swapped in and out on the fly. The applications can have multiple kernels swapped in and out of the FPGA during run-time without disrupting the interface between the server CPU and the FPGA for nonstop application acceleration. This functionality is ideal for swapping applications during peak loading periods.”
(Note: For more information about the Xilinx SDAccel design environment, see “CPU/GPU-like software development environment for OpenCL, C, C++ delivers FPGA-based app acceleration with 25x better performance/W,” “and “Latest SDAccel release adds 4 new hardware dev platforms, 4 new libraries, 6 new design services firms.”)
Vinay Singh accepts an ACE Award for the SDAccel design environment from Max Maxfield
The LabVIEW Communications System Design Suite from National Instruments (NI) won the ACE Ultimate Product Award in the Software category. NI’s LabVIEW Communications System Design Suite combines software defined radio (SDR) hardware with a comprehensive, unified software design flow to help engineers prototype 5G systems. The package includes built-in application frameworks for WiFi and LTE that enable wireless developers to focus on creating specific components based on existing standards rather than designing new algorithms from scratch.
The LabView Communications System Design software is coupled with the company’s USRP software-defined radio development platform for 5G research, which is based on a Xilinx Kintex-7 All Programmable FPGA. Wireless engineers can use the NI USRP RIO and the NI LabVIEW Communications System Design software to rapidly prototype real-time wireless communications systems and test them under real-world conditions.
(Note: For more information about the NI LabVIEW Communications System Design Suite, see “LabVIEW Communications System Design Suite combines SDR hardware with a unified software design flow for 5G development.”)
Congratulations to all of the talented developers from both National Instruments and Xilinx who created these award-winning products.

Highlight colors change (invert) on some backgrounds, i can make it back by changing use system colors and or background color, i would like to knoe if there is a setting to stop the change ?

i set my highlight colors to yellow background and black foreground in windows , it uses the same colors in firefox except as i highlight over some colors the foreground and background colors invert yellow on black , if there is a setting (or one can be added) in about:config to make the highlight always stay as yellow back and black foreground ? , im not sure if it is done within firefox though or if it is win xp but itcan be changed inside firefox about:config with browser.display.use_system_colors and/or browser.display.background_color .

that sort of makes sense but when you look at youtube messages , each alternate line is a very pale blue and when highlighted each alternate line the color is switched , this also happens on all web pages with simuler shading (not just pale blue) .
about the purple highlighting , ive never seen that , i have firefox on 2 PCs , a laptop and a notepad and they all use the colors set in win xp for highlight , even when use system colors is set to false , all that happens then is they swap about (invert) agen , i some times have to switch browser background color as well . sorry for being repetetive , im just trying to be clear , i have tried fine tuning BG color but on some pages just 1 single number away from white makes the switch,on other pages you can go nearly all the way to black befor it switches .ive just seen add images , ill send some pics to show what im trying to say .

Controls System Engineer-Labview and Teststand

One year experience in Labview and Teststand/automated testing system for Locomotives.Masters in Embedded Software. Seeking Employment Fulltime/Contract.

Hi,
Thank you for responding. I am based at USA. Currently looking for opportunities here.
Thanks!
Priya

Experienced LabVIEW developer and system integrator..

.. looking for a contract in north-eastern US or Canada.
If interested, would you please reply to my post.

Hi
I completed my M.S in electronics engineering and working with GE in INDIA since June 2005. I have total 2 years of experience with LabVIEW and have the follwoing skills.
Intermediate-to-advanced knowledge of LabVIEW.
Familiarity with data acquisition concepts and hardware.
Ability to troubleshoot electrical and electronic systems at the module and equipment level.
Discipline and organization with respect to software maintenance and version management.
Ability to work both alone and with colleagues to solve problems and to weigh the merits of differing approaches
you can reach me at [email protected]
Thanks & Regards
Anil Punnam
Message Edited by Laura F. on 03-16-2007 09:20 AM

System Colors in Color Box Constant

Hi,
I want to know how LabVIEW handles the values of system colors in case of a system change. For example:
I develop a VI on "System A" and choose the system color "Window" in the Color Box Constant. Now I run the VI on another "System B".
Retrieves LabVIEW now the system color "Window of "System B" or retrieves LabVIEW a fixed value from moment of development on "System A"?
Kind regards
Christian
Test Engineering
digades GmbH
www.digades.com
Solved!
Go to Solution.

It uses whatever colors are the system colors for the machine it is actually running on. So it would uses the colors from system B.
Likewise for fonts. If you uses any of the symbolic fonts like dialog, application, ... and they are tied back to the system fonts of dialog, application, menu (I might have those names wrong or mixed up) by way of LabVIEW's or the exe's "app" .ini file, it will use whatever the Windows fonts are. This can cause problems for an application where the front panel was sized based on an older OS where the system fonts were different and smaller when the app gets run on a newer OS such as Win7 where the font is something else, but also larger by a point or two.

When printing a VI as a PDF on MacOS that has system controls, the system color turns into a nasty yellow

The subject line says it all. Happens on multiple Macs--in fact, the problem was reported by a customer. When printing on a Mac, one of the options available instead of sending the output to a printer is to create a PDF file. For some reason, the system color is substituted with yellow. It also happens when saving a postscript file.
There is no code in this VI and it wasn't running, but the same problem happens with my built application.
How do I get out of this mess? I am using LabVIEW 2010. I have a huge UI with system colors used throughout.
Thanks

Hello travispape:
This particular issue has been reported to R&D; they are working on it. At this time, we have no target date as to when it will be fixed.
Kevin R.

Loops and system timestamp not synchronized

Running Labview 8.6.1 on Windows 2000, loops and system timestamp (Windows clock) seem to use different time bases; one second in a loop is not exactly as long as a second in system time. If i run a simple VI as in picture, with a 1-second loop which just prints the system time, the printed timestamp goes faster by about 1ms every 4-5 seconds. The same happens using a Timed loop or a While with a Wait until next ms multiple.
Why is that? Can i set a loop to match the system time?
Attachments:
1sec.png ‏3 KB

johnsold wrote:
In the eastern U. S. interconnected power grid the accumulated time is held to within a small fraction of a second when averaged over days. Over a year the accumulated error is less than parts in 10^12 or better. The instantaneous frequency can deviate from the nominal 60 Hz by less than 0.1 Hz.
The system basically uses an integral controller referenced to a NIST atomic clock to force the steady state error to zero.
Lynn
So is that a very technical way of saying "Ben, you are full of Sh#% !"*
I have not measured the frquency of my AC service in the last three decades or so. I do remember seeing it faster in the summer and slower in the winter. Has it really changed? Silly me thinking that the wide freq input spec I read on wall-warts was there just to handle this variation of freq.
And to think it has gotten smarter "without a brain".
Ben
* I am just trying to catch up what I seem to have missed. The above is all in good humor. No offense intended or taken.
Message Edited by Ben on 08-03-2009 12:56 PM
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Error -17600 when switching from LabVIEW Development System to LabVIEW Run-Time Engine in Adapter Configuration

I receive an error message (code -17600) while loading my test sequence after switching from LabVIEW Development System (2009 f3) to LabVIEW Run-TIme Engine using the Adapter Configuration.
ErrorCode: -17600,
Failed to load a required step's associated module.
LabVIEW Run-Time Engine version 9.0.1f3.
When I switch back to the LV development system, everything is OK, and the sequence loads and runs perfectly.
My TestStand Engine Version is 2012 f1 (5.0.0.262).
I'd appreciate any help on this issue.
Roman

Hi Roman,
There are a couple of things you can try:
1) Determine if the LabVIEW RunTime Engine is corrupted in some way. Create a new simple VI with no sub-VIs, using the same LabVIEW Development system you used for mass-compiling the VIs. Create a TestStand step that calls this VI and ensure it runs correctly. Now switch your LabVIEW adapter to use the RuntimeEngine and choose the "Auto detect using VI version" option.
Check if the simple VI is loadable and runs without errors in TestStand.
If the step generates the same error, you should try a re-install of the LabVIEW development system.
If not, its most likely that there is some VI you are using that is not loadable in the LabVIEW Runtime Engine because:
1) Some sub-VI is still not saved in the right version or bitness. Open the VI heirarchy of the top-level VI that you are calling from TestStand and examine the paths of all the sub-VIs to check if they were in the folder you masscompiled and re-save any that are outside this directory.
Also, when you try to close the top level VI, do you get a prompt to save any unsaved files? If so, they could be the sub-VIs that are not saved in the right version. Save all of them.
Check if you are loading any VIs programatically and if these are compiled and saved in the right version as well.
2) There is some feature you are using in your LabVIEW code that is not supported in the LabVIEW RunTime Engine. To check this, add your top-level VI to a LabVIEW project and create a new build specification and create a new executable from this VI.
    Right-click "Build Specifications" and choose "New->Application(EXE)".
    In the Application Properties window, select Source Files and choose the top level VI as the start-up VI.
    Save the properties.
    Right-click on the newly created build specification and choose Build.
Run this executable (it will be run using the LabVIEW RunTime) and check if the VI has a broken arrow indicating that it cannot be loaded and run in the LabVIEW Runtime Engine.
You might need to examine your code and find the feature which is not supported in the LabVIEW RunTime and find an alternative.
Another thing i forgot to mention the last time around is if you are using 64-bit LabVIEW with 32-bit TestStand, then executing code using LabVIEW RTE from TestStand will not work since the 64-bit LabVIEW RTE dll cannot be loaded by the 32-bit TestStand process.
If none of the above steps resolve the issue, consider sharing your LabVIEW code so i can take a look.
Regards,
TRJ

How to create a type of 'alarm event' based on acquired sensor data and system time?

Hello all,
I'm fairly new to LabVIEW and have successfully created a VI that reads voltage data from sensors. Each sensor outputs 2 voltage values and I treat these values as 2 different DBL values. I'd like to be able to record each voltage value as a base and then compare the subsequent data readings with that base. Once the base is determined, I'd like a sort of 'variable' set as "TIME" to be recorded at the moment the base voltage is recorded.
The alarm should occur (or anything Boolean set to TRUE I guess) once the continuously read voltage remains within certain limits for about 2 hours. I know I can compare the system time w/ the "TIME" that the voltage base value was recorded. If the voltage readings escape those limits, I'd like the voltage base value reset and the TIME set to the corresponding system time again.
I apologize in advance if this I haven't' described my problem well, but if anyone could help me figure out the best way to create this code, I would appreciate it much!
Thanks!
Solved!
Go to Solution.

ill try to illustrate a couple scenarios:
keep in mind that i dont necessarily want the voltages in these specific ranges, but just a range of +/- 20 mV ... in an above post i refer to a "base" voltage reading, in this case that would be 200 mV for V1 and 400 mV for V2, just because the voltage has shifted to those values for an extended amount of time each (> 2 seconds)
Scenario 1
1:00 pm
Sensor readings
Voltage 1: 200 mV
Voltage 2: 400 mV
between 1:00 and 3:00 pm:
Voltage 1 does not deviate from 180-220 mV range
Voltage 2 does not deviate from 380-420 mV range
at 3:00pm I want an alert/alarm/Boolean to change to 'true'
Scenario 2
1:00 pm
Sensor readings
Voltage 1: 200 mV
Voltage 2: 400 mV
at 1:45 pm:
Voltage 1: 2 mV
Voltage 2: 600 mV
Since the voltage has shifted out of the range, i want the new base voltage to equal whatever it changed to out of the range, and also the time spent within the new range (2 +/- 20 mV and 600 +/- 20 mV, respectively for V1 and V2) would be reset, so a new 2-hour counter would begin

Is this roughly how the labVIEW Execution Systems work?

I've not taken a class in OS design, so I don't know the strategies used to implement multitasking, preemptive or cooperative. The description below is a rough guess.
LabVIEW compiles Vis to execute within its own multitasking execution environment. This execution environment is composed of 6 execution systems. Each execution system has 5 priority queues (say priorities 0->4). Vis are compiled to one or more tasks which are posted for execution in these queues.
An execution system may either have multiple threads assigned to execute tasks from each priority queue, or may have a single thread executing all tasks from all priority queues. The thread priorities associated with a multithreaded execution system are assigned according to the queue that they service. There are therefore 5 available thread priority levels, one for each of the 5 priority level queues.
In addition to the execution queues, there are additional queues that are associated with tasks suspended in various wait states. (I don't know whether there are also threads associated with these queues. It seems there is.)
According to app. note 114, the default execution environment provides 1 execution system with 1 thread having a priority level of 1, and 5 execution systems with 10 prioritized threads, 2 threads per priority queue. NI has titled the single threaded execution system "user interface" and also given names to the other 5. Here they will be called either "user interface" or "other".
The "user interface" system is responsible for all GUI actions. It monitors the keyboard and mouse, as well as drawing the controls. It is also used to execute non-thread-safe tasks; tasks whose shared objects are not thread mutex protected.
Vis are composed of a front panel and diagram. The front panel provides an interface between the vi diagram, the user, and the calling vi. The diagram provides programmatic data flow between various nodes and is compiled into one or more machine coded tasks. In addition to it own tasks, a diagram may also call other vis. A vi that calls another vi does not actually programmatically branch to that vi. Rather, in most cases the call to another vi posts the tasks associated with the subvi to the back of one of the labVIEW execution system�s queues.
If a vi is non-reentrant, its tasks cannot run simultaneously on multiple threads. This implies a mutex like construction around the vi call to insure only one execution system is executing the vi. It doesn�t really matter where or how this happens, but somehow labVIEW has to protect an asynchronous vi from simultaneous execution, somehow that has to be performed without blocking an execution queue, and somehow a mutex suspended vi has to be returned to the execution queue when the mutex is freed. I assume this to be a strictly labVIEW mutex and does not involve the OS. If a vi is reentrant, it can be posted/ran multiple times simultaneously. If a vi is a subroutine, its task (I think there is always only one) will be posted to the front of the caller's queue rather than at the back of the queue (It actually probably never gets posted but is simply mutex tested at the call.) A reentrant-subroutine vi may be directly linked to its caller since it has no restrictions. (Whether in fact labVIEW does this, I don�t know. In any event, it would seem in general vis that can be identified as reentrant should be specified as such to avoid the overhead of mutexing. This would include vis that wrap reentrant dll calls.)
The execution queue to which a vi's tasks are posted depends upon the vi execution settings and the caller's execution priority. If the caller's execution priority is less than or equal the callee's execution settings, then the callee's tasks are posted to the back of the callee's specified execution queue. If the caller's execution priority is greater than the callee's specifications, then the callee's tasks are posted to the back of the caller's queue. Under most conditions, the vi execution setting is set to "same as caller" in which case the callee�s tasks are always posted to the back of the caller's execution queue. This applies to cases where two vis are set to run either in the other execution systems or two vis are set to run in the user interface execution system. (It�s not clear what happens when one vi is in the �user interface� system and the other is not. If the rule is followed by thread priority, any background tasks in the �other� systems will be moved to the user interface system. Normal task in the �other� systems called by a vi in the �user interface� system will execute in their own systems and vice versa. And �user interface� vis will execute in the caller�s �other� system if the caller has a priority greater than normal.)
Additionally, certain nodes must execute in the "user interface" execution system because their operations are not thread-safe. While the above generally specifies where a task will begin and end execution, a non-thread safe node can move a task to the �user interface� system. The task will continue to execute there until some unspecified event moves it back to its original execution system. Note, other task associated to the vi will be unaffected and will continue to execute in the original system.
Normally, tasks associated with a diagram run in one of the �other� execution systems. The tasks associated with drawing the front panel and monitoring user input always execute in the user interface execution system. Changes made by a diagram to it own front panel are buffered (the diagram has its own copy of the data, the front panel has its own copy of the data, and there seems to be some kind of exchange buffer that is mutexed), and the front panel update is posted as a task to the user interface execution system. Front panel objects also have the advanced option of being updated sequentially; presumably this means the diagram task that modifies the front panel will be moved to the user interface execution system as well. What this does to the data exchanged configuration between the front panel and diagram is unclear as presumably both the front panel and diagram are executing in the same thread and the mutex and buffer would seem to be redundant. While the above is true for a control value it is not clear whether this is also true for the control properties. Since a referenced property node can only occur on the local diagram, it is not clear it forces the local diagram to execute in the user interface system or whether they too are buffered and mutexed with the front panel.
If I were to hazard a guess, I would say that only the control values are buffered and mutexed. The control properties belong exclusively to the front panel and any changes made to them require execution in the �user interface� system. If diagram merely reads them, it probably doesn�t suffer a context switch.
Other vis can also modify the data structure defining the control appearance and values remotely using un-reference property nodes. These nodes are required to run in the user interface system because the operation is not thread-safe and apparently the diagram-front-panel mutex is specifically between the user interface execution system and the local diagram thread. Relative to the local diagram, remote changes by other vis would appear to be user entries.
It is not clear how front panels work with reentrant vis. Apparently every instance gets its own copy of the front panel values. If all front panel data structures were unique to an instance, and if I could get a vi reference to an instance of a reentrant vi, I could open multiple front panels, each displaying its own unique data. It might be handy, sort of like opening multiple Word documents, but I don�t think that it�s available.
A note: It is said that the front panel data is not loaded unless the front panel is opened. Obviously the attributes required to draw an object are not required, nor the buffer that interfaces with the user. This rule doesn�t apply though that if property references are made to front panel objects, and/or local variables are used. In those cases at least part of the front panel data has to be present. Furthermore, since all data is available via a control reference, if used, the control�s entire data structure must be present.
I use the vi server but haven�t really explored it yet, nor vi reference nodes, but obviously they too make modifications to unique data structures and hence are not thread-safe. And in general, any node that accesses a shared object is required to run in the user interface thread to protect the data associated with the object. LabVIEW, does not generally create OS level thread mutexes to protect objects probably because it becomes to cumbersome... Only a guess...
Considering the extra overhead of dealing with preemptive threading, I�m wondering if my well-tuned single threaded application in LV4.1 won�t out perform my well-tuned multithreaded application in LV6.0, given a single processor environment�
Please modify those parts that require it.
Thanks�
Kind Regards,
Eric

Ben,
There are two types of memory which would be of concern. There is temporary and persistent. Generally, if a reentrant vi has persistent memory requirements, then it is being used specifically to retain those values at every instance. More generally, reentrant code requires no persistent memory. It is passed all the information it needs to perform its function, and nothing is retained. For this type of reentrant vi, memory concern to which you refer could become important if the vis are using several MBytes of temporary storage for intermediate results. In that case, as you could have several copies executing at once, your temporary storage requirements have multiplied by the number of simultaneous copies executing. Your max memory use is going to rise, and as labview allocates memory rather independently and freely, the memory use of making them reentrant might be a bit of a surprise.
On the other hand, the whole idea of preemtive threading is to give those tasks which require execution in a timely fashion the ability to do so regardless of what other tasks might be doing. We are, after all, suffering the computational overhead of multithreading to accomplish this. If memory requirements are going to defeat the original objective, then we really are traversing a circle.
Anyway, as Greg has advised, threads are supposed to be used judiciously. It isn't as though your going to have all 51 threads up at the same time. In general I think, overall coding stategy should be to minimize the number of threads while protecting those tasks that absolutely require timely execution.
In that sense, it would have been nice if NI had retained two single threaded systems, one for the GUI and one for the GUI interface diagrams. I've noticed that control drawing is somewhat slower under LV6.0 than LV4.1. I cannot, for example, make a spreadsheet scroll smoothly anymore, even using buffered graphics. This makes me wonder how many of my open front panel diagrams are actually running on the GUI thread.
And, I wonder if threads go to sleep when not in use, for example, on a wait, or wait multiple node. My high priority thread doesn't do a lot of work, but the work that it does is critical. I don't know what it's doing the rest of the time. From some of Greg's comments, my impression is it in some kind of idle mode: waking up and sleeping, waking up and sleeping,..., waking up, doing something and sleeping... etc. I suppose I should try to test this.
Anyway that's all an aside...
With regard to memory, your right, there are no free lunches... Thanks for reminding me. If I try this, I might be dismayed by the additional memory use, but I won't be shocked.
Kind Regards,
Eric

I pull fiftyfour bytes of data from MicroProcessor's EEPROM using serial port. It works fine. I then send a request for 512 bytes and my "read" goes into loop condition, no bytes are delivered and system is lost

I pull fiftyfour bytes of data from MicroProcessor's EEPROM using serial port. It works fine. I then send a request for 512 bytes and my "read" goes into loop condition, no bytes are delivered and system is lost

Hello,
You mention that you send a string to the microprocessor that tells it how many bytes to send. Instead of requesting 512 bytes, try reading 10 times and only requesting about 50 bytes at a time.
If that doesn�t help, try directly communicating with your microprocessor through HyperTerminal. If you are not on a Windows system, please let me know. Also, if you are using an NI serial board instead of your computer�s serial port, let me know.
In Windows XP, go to Start, Programs, Accessories, Communications, and select HyperTerminal.
Enter a name for the connection and click OK.
In the next pop-up dialog, choose the COM port you are using to communicate with your device and click OK.
In the final pop
-up dialog, set the communication settings for communicating with your device.
Type the same commands you sent through LabVIEW and observe if you can receive the first 54 bytes you mention. Also observe if data is returned from your 512 byte request or if HyperTerminal just waits.
If you do not receive the 512 byte request through HyperTerminal, your microprocessor is unable to communicate with your computer at a low level. LabVIEW uses the same Windows DLLs as HyperTerminal for serial communication. Double check the instrument user manual for any additional information that may be necessary to communicate.
Please let me know the results from the above test in HyperTerminal. We can then proceed from there.
Grant M.
National Instruments

JPG and TIFF colors in Bridge CS5 way off, but fine in Photoshop

Just started happening, but not sure if it was after updating to Bridge 4.0.3 or Camera RAW 6.2. The colors for RAW and PSD files are fine in Bridge, but all JPGs and TIFFs colors are blown out and way off. Opening the JPG or TIFF in Photoshop looks fine though. Anyone else having this issue, or know how to fix it?
Update: If I set the "Develop Settings" in Bridge CS5 to "Camera Raw Defaults" for the JPGs/TIFFs that are displaying improperly, the colors and tones go back to normal, but if I "Clear Settings" everything turns to crap again.

PLEASE help save my sanity and my reputation! --I have spent the last five days exhausting every possible solution to this debilitating issue. I have spent countless hours perusing the web for a solution, spent 4 hours yesterday with Adobe customer support and yet, there is no solution to be found. My issue is that the color (in every file format NEF, JPEG, PSD) completely changes color and desaturates in every one of the adobe products: Photoshop CS5, Camera RAW 6.2, Lightroom 3.2. -
Everything was working fine, and then out of no where my productivity has come to a crashing halt. This is the steps I have taken to this point:
-Uninstalling/re-installing all of the software
-Purging anything that can be purged.
-Changing color profiles
-Resetting defaults
-Resetting preferences
-Installing updated drivers for monitor, video cards
-rollling back drivers for monitor, video cards
-monitor recalibration
**and finally, today...I set the monitor up on another computer, OS windows xp, and to my complete surprise, the issue persists even on another pc with completely different hardware.
-I am at my wits end with this. I have clients ringing my phone off the hook. This is crazy!
-I have sent out for another monitor as a last ditch effort to see if something is wrong with the monitor.
PLEASE, if anyone has a solution please let me know. Apparently, the folks at Adobe are just as perplexed by these issues as we are, as I have found numerous posts on forums throughout the Internet with this same issue---and yet none of the post every found a solution.
Primary System
Windows7 64-bit
Nvidia fx 580 video card
Dell U2410 Ultra Sharp Monitor
Abobe CS5 Photoshop -64-bit
Lightroom 3.2
Camera Raw 6.2
Secondary
Windows XP
Nvidia GeForce 8400gs
Same software, just in a 32-bit

LabView and System Colors

Similar Messages

Maybe you are looking for