robijn

Error 56 sounds logical. It only means that there was no data received in time. This has nothing to do with the TCP timeout (which I think you cannot set from within LabVIEW). If you only read and don't receive anything the connection is not considered lost at all. The other side just didn't send anything. It is only after some data is tried to be send and no acknowledge is received from the other side that the TCP layer will say that the connection is lost. But that is usually only after a considereable time (at least half a minute but possibly a few minutes). This is why it is often good to have some form of keep-alive built into your app, a packet that is sent from both sides at regular intervals. At least then you detect when the connection is lost. Joris

I would love to have more pie in LabVIEW ! Joris

I reported this as well, but it was discarded as "not a bug". I also think you should be able to define what you want, or how you want to see it, and that LabVIEW should not try to think for the programmer. It may be that the programmer simply made a mistake. If LabVIEW suddenly thinks it can solve the problem by replacing the VI with the more generic one, this may have consequences that the compiler could never had thought of. We all know that when computer starts to think for us, things go wrong For example, we have an appliaction that feed birds by calling a Bird.feed method. If we by accident wire a Bear to this method LabVIEW automatically replaces the Bird.feed VI with the more generic Animal.feed VI. This may yield unexpected problems because feeding Bears is a different ball game. We should have taken precautions before we started feeding the Bear. To a non-OO programmer this may sound far-fetched because we don't deal with Bears in LabVIEW, but similar problems occur with programs. As a programmer we know the classes we work with. On some classes we can do actions immediately, but on others the same method may require other things to be done first. If we wanted to be able to feed all animals including bears, we had written a method that was able to do that and had allowed Bears to be fed as well, by specifying Animal as the input type. If LabVIEW adjust the output type to what it sees in the diagram going into the VI, this can have unexpected effects on things further on in the program. If you have to specify, at least you have thought about it. Joris You could add an option at the method call named "adjust output type to input". It would best give a visible "bumb" on the output to indicate that it is automatically casted. You would then keep be able to have predictable visible behaviour under all circumstances. Joris

I've seen something related (most probably already reported too). It seems an array control or constant can remember that it was wired to a fixed size array. Then when you paste it somewhere else, the array wire does not allow to be changed size anymore. I was unable to remove the problem changing control/wire properties or by setting FPGA options off and restarting LV. Workaround: create the wire/control again from scratch.

There are many I2C to serial converters (especially multiple port devices) that have similar problems with VISA. Some or all functions then don't work (properly). I have very good experience with Prolific drivers, all devices with Prolific drivers always work. Joris

Stephen, I hope you now understand my "obnoxious" remark. I think many, many programmers got irritated by the optimization problems. As a professional I can hardly explain my customers that for most applications we still prefer 7.1.1 (not only for stability reasons). All I would suggest is to take less risk and to keep basic things as they are. What you need as a professional programmer is a good basis, all the rest you can add yourself with helper VI's, tools etc. With a good basis we can sell LV programs that do not give the customer nor us any headaches. Joris

... and loose all the advantages of having such a thing. Speed, compactness, clarity. Joris

Indeed, I've also relied on that many times. If the behaviour is to be changed (which would not be a bad thing on itself IYAM), the automatic version upgrade process should replace the U32 or I32 nodes by Typecasts nodes. Because from the Typecast function that behaviour is expectable. I find it strange that the typecast node sometimes modifies data. It should never do that. Joris

Hi, You'll have a hard time debugging apps like this. And making any extension to it will especially be difficult. You can check each time if the valueof a combobox has changed, but it's much easier to detect it with an event structure and a value change. I see you did use the shift register to store the comm transcript. If you go for some state machine / queued message handler (for example the one I proposed to you earlier) you should put that string in the state cluster. Joris

BTW, variants are about 50x faster in LV8 than in 7. At least if you know the stored type correctly. Good job NI, I do like these kinds of optimizations ! Joris

No, because it does not allow compile-time checking. You would have to run your program in order to find problems in your wiring. If you want to see more about template problems in other languages have a look at this: http://burks.brighton.ac.uk/burks/pcinfo/p...it/index003.htm, chapter Templates. Joris

I know about template trouble in C. But unlike C, LV already has its way of determining propagating datatypes of wires, which would work here as well. What problems do you see ? Joris

Yes for these examples you are certainly right. But then, how far should the optimization go ? Because optimization creates a risk, as we've all seen ... Joris

I would like to propose the typeless wire. Along with that comes a typeless control and indicator. Black might be a good colour. It's a bit like a template type in C, but then better because it's LabVIEW Actually the proposed wire is only typeless in the diagram of the VI concerned. As soon as the VI is placed somewhere as a subVI, the connections made to the VI determine the actual type of the wires inside the VI. For example, you could make a VI with a typeless input and output, place an array resize function in the VI that resizes a connected array to be able to set an element (as in picture above). It would work on any 1D array that is connected. Whether the VI is compilable or not depends on the type of wires that are connected where it is placed. The type of a typeless output terminal is also determined by these connections. To keep the behaviour similar to normal VIs, the VI should lock like any other VI, so that only one instance can be running at a time. Extra code will be generated for the type of wires that are connected. There should not be completely different instances of code for each type, because a great part of the code can be shared between different types. The compiler can insert a branch instruction when a typeless wire is reached, to jump to the code required to execute an action for the wire of the specific type. If you would connect a typeless wire to a shift register, each type would generate its own instance of the shift register. However, if a normal (typed) wire is connected to an another shift register in the same VI, that shift register is shared between all types. That way you could for example create a "generic" storage functional global. To be able to do different things for different connected types, the case structure could be used to switch between the various behaviours. It would then switch based on the wired type. E.g. if you create case frames for a DBL and a Boolean, the VI is compilable for those types. The wire is available in the case frame as of this type. It would allow you to return a string for both a double and a boolean: "3.14" and "True". If a type is connected to a typeless input of the VI for which there is no case frame, the VI is not compilable. This mechanism as an alternative to polymorphic VIs. Polymorphics require multiple VI's, with often identical diagrams, which causes code duplication. Untyped wires allow to have only a single diagram for multiple types. They are easier to manage and understand, give smaller code and don't require all the types to be known and implemented beforehand. Something for LV9 ? Joris

Don't worry I did not see it I meant it as an ironic marketing line. Usually marketing departments introduce new features that are better, faster, more reliable. Usually that goes for something that was "added". But you don't hear them about negative consequences of the addition. So I turned everything around, made an improvement of a removal, just to make a point. It seems it hit harder than intended. If you think about the folding optimizations, they hardly give any improvement because a reasonable programmer will always think about the program he's writing. If the programmer places a loop that does nothing, he just didn't think enough. The same goes when he could better have placed a calculation outside a loop. Many inefficiencies cannot be detected by an optimizing compiler, because they are caused by an efficient structure of the program. There's always a bottleneck in any program, and no matter how good the compiler optimizes, the compiler cannot improve the design. The problem is usally with the programmer, not with the compiler. So improving the user may give much larger speed gains. This may sound like a stupid statement but it is possible to learn a programmer better ways of programming. More optimizations always requires more code. And more code will introduce more bugs. I really cannot understand why NI decided to do this. It is dangerous and there's no real gain. It only undermines the stability, reliability and clarity, and those are important factors when you are working in environments where LV is often used. LV is not an office application. To come back to your question, I think these folding optimizations are something different than a loop speed optimization because loop speeds are a hard limit. The program cannot loop any faster than the LV generated code allows it to. Then, generating better looping code has gain. But all folding optimization gains can also be achieved by the programmer writing his program slightly more efficient. That's why I consider them different. Joris

Why not ? Shouldn't the 7.11 just work if loaded in LV8.20 ? Or does it work ? Joris

You have now three actions in a single VI, and you cannot perform multiple actions triggered by buttons. 1. You need to split this into three subVIs: open device, query device and close device. (replace "device" by the name of your device.) 1.1 Create subVI's for them. Test them by running them individually. 1.2 Give them the connector pane with 12 connections (default in LV8) 1.3 Connect the connector pane. Connect the error connectors and text/data input/output connectors. Keep left for input and right for output. Connect error in and error out to the bottom left and right connector. 1.4 Give them an icon with short text describing their function. 2. Create the basis for a "real" program. 2.1 You will at least need a while loop. 2.2 Better would be to use what is called a Queued Message Handler. I've attached a simple template of one, that you could use. Read more on how QMH's work on the NI site or maybe on this site. It's a template only, you will need to adapt the VI to suit your needs. 2.3 Add the button actions in the user event handling part of the QMH. Create new separate actions by modifying the Type definition of the enum. Call those actions from the event structure. 2.4 When doing the actual actions for the buttons, in the frames of the case structure, call the "query device" VI created in step 1 to perform the communication. 2.5 You can update the string indicator by storing the full communication transcript in the state shift register of the QMH, and appending new data to that string when it arrives. You will need to find out how a shift register works and how bundling and unbundling clusters works. Update the string on the front panel by calling the update display state. How to actually do many of these things will cost some time to find out yourself, but I hope I can give you some line of what things need to be done, what direction to go. Work these points one by one. If you cannot do a next point, you did not study the previous point sufficiently If you manage to do all this you have a pretty decent program. Joris Download File:post-1555-1168506856.zip

Best feature of LV9: No more constant folding ! More reliable programs without any practical loss of speed and linking VI's in statically becomes more consistent ! :thumbup: Joris

On modem-like connections it's usually \r (carriage return). There's a constant for it in the palette. You can place the \r and \n chars the Format Into String format input as well. You could, if you set \-mode for the control or constant. Help on event structure. (Can't imagine my answers are long... ) Joris

I think X was meant to stand for "the unknown, the mysterious", like in the X-files... Things that noone really completely understands, but are very interesting to explore. Joris PS. I do like the concept of X controls !

You can't learn a language in one day... Some things even work competely different in labview than in any text based language. For example: your connections dictate the execution sequence, but by default everything is executed in parallel... No you have to do that yourself. You could iterate over the COMx ports and send something and check what comes back. You can format a string in a C like way with Format Into String, so you can build a "COMx" string and wire that to the VISA function. On itself that's true but you probably need to set the speed etc first anyway. Yes, you can find it on the palette. Because the string indicator/control can be resized and given a scrollbar. You could use an event handler to handle the button presses and typed texts. You could continuously set the cursor at the last position in the text so that it "types" like a terminal. No problem. Have a look in the help and examples. Wiring the error wire through is the best way to make a sequence of actions. One of those action could be a wait function. For your each specific problem search the NI forums: forums.NI.com There is lots of info on communicating with devices in various protocols. Success, Joris

Yes, right now they are called as a handler. NI could change the behaviour and make them run continously. I have often many windows running in parallel, handling their own events. New data could arrive in the event structure. I like the idea for registering properties, creating custom events. Joris

Judging by the name "get all front panel controls", I wrote VI's doing similar things and because that was implemented with property nodes, I set them to run in the UI thread, preventing thread switches. Because it was in 7.1.1 I did not have your slowdown problem, but running in the UI thread gave an enormous speedup already. Maybe the slowdown is caused by a bug in the thread switching. Maybe you can try running this VI in the UI thread (if not already). Joris

Well Aristos, that's a very nifty feature ! All other methods have the problem of "what do you rename to what" and like this you have a perfect solution for that. My compliments for the excelent idea (to whoever at NI that came up with it). Joris

Yes, which idiot introduced that I always use the attached VI called Suppress error codes.vi which removes given errors from the wire. The errors to remove/suppress are specified with an I32 array. When one of those errors has been found it is removed and a boolean indicator is set so you can respond to the error. You could then create your own error instead of the old one, or perform some action. It also removes warnings that match the given number so you can also remove for example the VISA warning for "More characters are waiting in the buffer" (of which I don't know the error code because it is specifically chosen to be impossible to remember). Joris Download File:post-1555-1166086583.vi