Jump to content


  • Content Count

  • Joined

  • Last visited


Everything posted by aledain

  1. The first thing to do is to check that the cable connections are correct. The intrument may require a null modem cable (where the transmit and receive pins (2,3) are reversed) or it might (rarley) do the crossover for you and require a straight through cable instead. Next check the pinout for the cable matches that for the instrument, especially if the instrument is D25 type connector, say and your PC com port is D9 type of connector. The next things to try are changing the baud rate, parity, stop bits, etc to match that specified in the instrument documentation. Then start playing with the c
  2. Doesn't turning off Y scale autoscaling work? You could then programatically set the top and bottom shown plot. N.B. I haven't tried it but IMHO it should work this way. cherrs, Alex
  3. But you could combine all your controls into a single cluster, change the code to a subvi with a cluster reference into it. In your application create several copies of the cluster and wire the cluster references to copies (as required) of the subvi. You can also modify/edit controls (use the spanner) quite extensively including removing parts or hiding bits of them (and including pictures) so perhaps a normal control could be modified too. For a pie chart might a guage work? cheers, Alex.
  4. And a quick google for "software easter eggs" reveals whole sites devoted to them! Didn't realise they were so prevalent. The first one I saw was in October 1995 where under Win3.1 the icon changed on Halloween. You're right about trust. I think I will notify them of my intent to add the egg with their permission. Anyone know of any eggs in LabVIEW? cheers, Alex.
  5. Hardly rambling, but a very instructive reply. I think that you're right about the possibility of damage being minimal, and that the advantage of the "fun" aspect should not be ignored. I agree too with your comment on the lack of a backdoor == loss of productivity. FWIW I have placed TRACE=TRUE as a possible configuration option in all(most?) of my applications for just such scenarios. Wading through a trace file can be more instructive than receiving a "it won't work" call ;-) I suppose the backdoor should/can be treated differently than the easter egg because the backdoor can be used bot
  6. No haven't read that, but have read some of his others. I'll now have to go out and buy it just to understand that cryptic comment ;-) cheers, Alex.
  7. I have the desire to place an easter egg (*) in an application I am working on. Should I inform management that the egg will go in? Can/should I do this and what are the ramifications (legal, moral, ethical, etc). Does this fall into the category of malicious code (even if the code is benign). And what about back doors. Has anyone placed one in software they have released? Hmm, much to ponder. cheers, Alex. * An easter egg is a small amount of code added as a bit of fun by a programmer. Generally they can be a bit of fun or a bit of a time waster, and they are NEVER malicious, hence the cu
  8. I have a need to make a VI extremenly thin (a special dialog). When I try and resize the VI in the edit environment it does not go thinner than a certain width. Do I need to do this programmatically or is there a way to remove this limitation? 6.02 code only please :headbang:
  9. Couldn't you create a date string using this instead of needing to replace the ":" ...
  10. Yes ... and no. They are less efficent, but for the efficiency reasons you list, they're efficient. The real trap (IMHO) is that they disrupt dataflow and as your program expands globals can (and more often so with inexperienced LV programmers), lead to race conditions. Once you have a complex program, tracking race conditions becomes difficult, tiresome, wearying, frustrating, etc, etc because when the pressure is on, locating a race condition that is there in the built exe but never occurs under the development environment, could send you mental. This is exacerbated when more than one d
  11. On linked constants, I think there are certain instances where the constants created from a strict typdef are not linked (might be cut and paste, might be older versions of LV too). I always check by RMB on the constant to see that "Update" is selected.
  12. Create a vi and save to your user.lib directory. From LV choose to edit palettes (under >6, pin the palette, chose the right most button and then select the "EditPalettes" button) and navigate to the User Library palette. RMB and choose Insert to have your VI appear in the palette. While you are there, select "MergeVI" as an option. Save your palettes and back in LV when you drag your new user.lib VI onto the diagram it only adds the code and front panel from your user.lib VI as a snippet, NOT as a subvi. This is a "merged" vi code snippet. Neat ;-)
  13. It changes the description for that instance of the while loop etc, not the default for all while loops. Note that you can also display a label (just like on a front panel) using the RightMouseButton (RMB) click, for structures and functions (except wires). P.S. You could probably create a default description for a while loop and add this "new" while loop as a code snippet to your user.lib, but that's probably not what you're after. cheers, Alex.
  14. You can set help (RMB, Description and Tip) for anything, including wires and case structures etc, then turn on flyover help (Ctrl-H) to see your comments.
  15. Wow! LabVIEW is not linear at all!! The reason that the buttons do not respond is that they are in the same while loop as your communications. (LabVIEW reads the state of the buttons just once per loop iteration, turn the globe on to see what I mean), so the buttons don't get re-read until the next iteration of the while loop. Move your communications into a separate while loop and then your GUI will respond in a more timely fashion. However, this does not solve your problem really, in that once the communication starts, your program needs to be able to interrupt it, so you'll need to do som
  16. Far far far simpler than that, use a separate while loop for your dialog box and a separate loop for your serial port stuff. This is classic LabVIEW and one of the powers of LabVIEW over other languages. use globals (as a starting point) to transfer data between your loops. More advanced mechanisms for this transfer (queues, notifiers, semaphores, etc) are available but not necessary. BTW, this is not multi-threading, so since both while loops are running in the same loop. So I like to refer to this as multi-fibred. LabVIEW is multi-threaded but for 99% of the world's programs you can get awa
  17. OK you need to look hard at what he's doing here. I think he's probably got a wait until next multiple timer timing this loop. You really need to look at buffered image acquitision. IOW, get the card acquiring using it's own clock, and every now and again pull all the images abck from it, selecting the appropriate one) ie if you acquire a frame evey 20ms, take the 5th one. I'd definitely change the WaitUntilNextMultiple (looks like a metronone, WUNM) to the Wait (looks like a watch). The difference here is subtle. If the WUNM is set to 1000 and the CPU is full throttle, then you might see a r
  18. Didn't realise remote panels did this. An alternative would be to use something like VNC. However, ... Hmmm, error prone? I think we need some more information about what you're trying to do in LabVIEW itself. The CPU usage should be close to zero (or ~10% say) with any normal LV application, especially one written using events. So this may mean you're not doing the LV part as efficiently as you can. Are you doing DAQ, some sort of PID or something? Remember LV was written for clunky 486 machines (my LV irrigation system at home runs on one!). Another first time mistake is to not put a wai
  19. There is a ping VI in the NI knowledge base somewhere. I also have one contributed by a generous sole. However, can a small app be written for each of the key machines that sends a message every N seconds. If your monitor PC does not receive that message every N + a little bit, seconds, then the PC is dead or off the network. Sort of like a watchdog. You could use TCPIP or datasocket for a quicker implementation. As for the message, I'd get it to send it's IP address.
  20. To send strings back: on your server just do a write operation after the read of the client message ... Client : WriteMsg, ReadMsg(with timeout 60 sec) Server: ReadMsg(with timeout 60 sec), writemsg cheers, Alex
  21. You can also run both the client and the server on the SAME PC, makes debugging real easy cheers, Alex.
  22. aledain


    LabVIEW Technical Resource : www.ltrpub.com/ But you'll need to order a back issure from them. cheers, Alex.
  23. Don't know anything about VB's callback, but the way I have done this in the past is to pass a reference to an occurrence into the DLL. The DLL code sets the occurrence and the LV code sits waiting for the occurrence to fire. Using the new custom events I bet you could get the setting of the occurrence to trigger a user event. // Note in pseudocode only, I cannot remember the real details eg. Public Event CallBack(stimer As Integer, occ As UnsignedInt32) ... Do While CSng(Timer) < (Start + Duration) If CSng(Timer) > (Start + Threshold) Then occ=1 ... BTW, all the code in the DLL
  24. Don't think you can hide individual tabs, but you can disable them. Look for the appropriate property node. You can also hide all the tabs using a right mouse click and selecting the appropriate drop down menu. As a workaround you could hide all the tabs and display just a string indicator of which is the current TAB above the top left corner. cheers, Alex
  25. aledain


    You can send all of these across the one connection. The trick here is to add a header byte to each packet so that your receiver (client) knows what to do with the packet. eg 0=synchro, 1=ttl, 2=audio, etc). Just a note on the audio: you will need to buffer the audio on the client side to avoid having playback that has gaps in it. There is an interesting article in one of the recent LTR issues dealing with LabVIEW, sound and gapless buffered sound playback using the native LV sound VIs. Well worth a read. cheers, Alex.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.