LabVIEW
Question about Global Variables and String Outputs
Hi Sid,
@sidnchan wrote:
I have two serial ports connected to Labview and have created commands to execute for these two ports. I have used a case structure to communicate with each serial port. At the moment, I have two terminals displaying the output of these commands for each port.
I want to combine these two terminals into a single output terminal, but have had little success. The closest I have gotten is by creating a global variable and attaching it to the same line that each string indicator is connected to.
So you have a problem with your code, but you don't attach that code for us!?
How should we help with your code problems, when all we get are just some sentences describing your problem?
Please attach code. Real code, not just images (of parts) of code.
(And in case you are using LV2021: File->Save for previous to address a broader audience…)
Why do you think a global variable might help to connect two data sources to just one data sink? (You know LabVIEW is all about "THINK DATAFLOW!"?)
@sidnchan wrote:
It won't let me connect the global variable to a string indicator because the variable itself is an indicator type.
Right click the global instance, select 'Change to Read' to change it to read.
Globals are not control or indicator, they are globals. You can read and write to any global.
Globals are not the solution here though (they never are). However, we need code to recommend a good solution.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
@sidnchan wrote:
It won't let me connect the global variable to a string indicator because the variable itself is an indicator type.
Right click the global instance, select 'Change to Read' to change it to read.
Globals are not control or indicator, they are globals. You can read and write to any global.
Globals are not the solution here though (they never are). However, we need code to recommend a good solution.
Globals have their place. They're not inherently evil, but they do have very specific usage cases. (This is not one of them.)
@billko wrote:
wiebe@CARYA wrote:
@sidnchan wrote:
It won't let me connect the global variable to a string indicator because the variable itself is an indicator type.
Right click the global instance, select 'Change to Read' to change it to read.
Globals are not control or indicator, they are globals. You can read and write to any global.
Globals are not the solution here though (they never are). However, we need code to recommend a good solution.
Globals have their place. They're not inherently evil, but they do have very specific usage cases. (This is not one of them.)
(Resisting the urge to comment on the place globals have 🤣. Almost succeeded.)
I didn't say they're evil, just that they are never the solution 😉.
Globals can appear convenient, but there are always better solutions. Sometimes the alternatives are only marginally better, but usually by far. The alternatives are often a lot more work, and the downsides of globals usually come out when sizing up which might never happen. So, not for me, but YMMV.
@sidnchan wrote:
I have two serial ports connected to Labview and have created commands to execute for these two ports. I have used a case structure to communicate with each serial port. At the moment, I have two terminals displaying the output of these commands for each port.
I want to combine these two terminals into a single output terminal, but have had little success. The closest I have gotten is by creating a global variable and attaching it to the same line that each string indicator is connected to.
When I double click and maximise the global variable, its front panel prints out exactly what I want, which is one string indicator containing messages from both serial ports in the front panel. But I'm not sure how to place this in my main front panel. It won't let me connect the global variable to a string indicator because the variable itself is an indicator type.
Any assistance would be greatly appreciated.
As others have hinted, it probably would help to describe and define the problem better. It would also help to go over the basic LabVIEW tutorials. A global can be set to read of write, so you probably just need to occasionally read and display it, for that, you need a loop and familiarize yourself with the principles of dataflow. However, I strongly suspect that you don't need any globals at all. The wire is the variable.
If we assume that each case communicates with a different serial port, all you probably need is place a plain string indicator after the case structure! No need for any globals and such.
Obviously, your description so far is very confusing and it would have helped to attach your VI.
- A serial port does not "connect" to LabVIEW. It connect to a serial port. You can use LabVIEW to interact with the serial port.
- A case structure cannot communicate with a serial port. It's what's inside the case structure that counts.
- The value of a global variable should not depend on the window size (maximised or not), so I am not sure what you are saying..
- A front panel does not print anything.
If both serial ports are configured similarly, virtually all communication code can be outside the case. All you need is switch the instrument with a select node, no case structure needed.
(This code is of course incomplete, but should show the principle)
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@sidnchan wrote:
It won't let me connect the global variable to a string indicator because the variable itself is an indicator type.
Right click the global instance, select 'Change to Read' to change it to read.
Globals are not control or indicator, they are globals. You can read and write to any global.
Globals are not the solution here though (they never are). However, we need code to recommend a good solution.
Globals have their place. They're not inherently evil, but they do have very specific usage cases. (This is not one of them.)
(Resisting the urge to comment on the place globals have 🤣. Almost succeeded.)
I didn't say they're evil, just that they are never the solution 😉.
Globals can appear convenient, but there are always better solutions. Sometimes the alternatives are only marginally better, but usually by far. The alternatives are often a lot more work, and the downsides of globals usually come out when sizing up which might never happen. So, not for me, but YMMV.
I don't about "by far"; most of them seem pretty technical and specific to certain use cases, but for what globals are made for - that is, holding write once/read many data - they work just fine.
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@sidnchan wrote:
It won't let me connect the global variable to a string indicator because the variable itself is an indicator type.
Right click the global instance, select 'Change to Read' to change it to read.
Globals are not control or indicator, they are globals. You can read and write to any global.
Globals are not the solution here though (they never are). However, we need code to recommend a good solution.
Globals have their place. They're not inherently evil, but they do have very specific usage cases. (This is not one of them.)
(Resisting the urge to comment on the place globals have 🤣. Almost succeeded.)
I didn't say they're evil, just that they are never the solution 😉.
Globals can appear convenient, but there are always better solutions. Sometimes the alternatives are only marginally better, but usually by far. The alternatives are often a lot more work, and the downsides of globals usually come out when sizing up which might never happen. So, not for me, but YMMV.
That's an old joke, and it is a joke. A guru wouldn't name a global (nor indicator) 'Boolean'.
@billko wrote:I don't about "by far"; most of them seem pretty technical and specific to certain use cases, but for what globals are made for - that is, holding write once/read many data - they work just fine.
That's not the problem. Of course they do what they are supposed to do.
The problem is that in using them you potentially couple code more tightly, bypass dataflow and often prevent opportunities for using your code more then once in the same code (which isn't a problem if the global is truly a global).
In functional programming, implicit input (vs explicit inputs) is an absolute no-no, as it makes testing a lot more difficult. I'd have to look up the wording, but the argumentation against implicit inputs are pretty compelling, and not just theoretical. Testing code that only depends on by value inputs is a lot easier then code that has 'state' (globals, references, shift resisters, locals, etc.).
Globals fit a 'pragmatic' programming style, and they do indeed do as advertised. I'm all for pragmatic programming, but globals are to far south of that spectrum for me. They just don't solve enough of my problems, compared to the problems they cause.
But if they work for you, great! We all work under different circumstances...
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@sidnchan wrote:
It won't let me connect the global variable to a string indicator because the variable itself is an indicator type.
Right click the global instance, select 'Change to Read' to change it to read.
Globals are not control or indicator, they are globals. You can read and write to any global.
Globals are not the solution here though (they never are). However, we need code to recommend a good solution.
Globals have their place. They're not inherently evil, but they do have very specific usage cases. (This is not one of them.)
(Resisting the urge to comment on the place globals have 🤣. Almost succeeded.)
I didn't say they're evil, just that they are never the solution 😉.
Globals can appear convenient, but there are always better solutions. Sometimes the alternatives are only marginally better, but usually by far. The alternatives are often a lot more work, and the downsides of globals usually come out when sizing up which might never happen. So, not for me, but YMMV.
That's an old joke, and it is a joke. A guru wouldn't name a global (nor indicator) 'Boolean'.
@billko wrote:I don't about "by far"; most of them seem pretty technical and specific to certain use cases, but for what globals are made for - that is, holding write once/read many data - they work just fine.
That's not the problem. Of course they do what they are supposed to do.
The problem is that in using them you potentially couple code more tightly, bypass dataflow and often prevent opportunities for using your code more then once in the same code (which isn't a problem if the global is truly a global).
In functional programming, implicit input (vs explicit inputs) is an absolute no-no, as it makes testing a lot more difficult. I'd have to look up the wording, but the argumentation against implicit inputs are pretty compelling, and not just theoretical. Testing code that only depends on by value inputs is a lot easier then code that has 'state' (globals, references, shift resisters, locals, etc.).
Globals fit a 'pragmatic' programming style, and they do indeed do as advertised. I'm all for pragmatic programming, but globals are to far south of that spectrum for me. They just don't solve enough of my problems, compared to the problems they cause.
But if they work for you, great! We all work under different circumstances...
I will do a deep dive into what you said so I can potentially become a better developer.
