Jump to content

Ravi Beniwal

Members
  • Posts

    97
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by Ravi Beniwal

  1. ...

    Note about ui rendering on Windows Seven : Probes was originally designed on Windows XP. Using them on Windows 7, we've came across some ugly ui rendering following OS display settings.

    ...

    We've tried to mange it as best as we've can, feel free to give us feedback on this point.

    Hi Olivier,

    I ran into these issues recently. Like all generalizations, this one may be wrong, but here was my observation!

    When you are switching from an XP machine to a Win7 machine, there is a pretty good chance that you are also moving to a higher resolution screen. I noticed that the system and dialog font on Win7 machines are set to a larger font then XP machines so that the physical size of the letters doesn't get too small on the higer resolution screens.

    To accommodate this larger test, all controls grow (and not always nicely), overlap, and just look weird.

    In this case, since the probes will always be used by nice friends like us :) and not in delivered products to customers (where you don't know who dislikes what), you can safely change the font on all text on the probes to a common fixed font like Tahoma 13pt or something. Within the development environment, we care more about getting access to the right information for debugging and wouldn't mind that you deviated from the recommended Dialog or System font.

  2. Hi Alex,

    In your FPGA Control Loop, you have the error wired to a shift register on the while loop. In case of an error, you are enqueuing an error command, but are also passing the error from that iteration f the while loop to the next through the shift register.

    So in the next iteration, the Dequeue Element sees the error wired in. It does not execute to pass on the "error" message you enqueued, instead it passes the control with an empty deueued element, which of course will give you an empty string. That is why the loop goes to the default typo handling case.

    Fix: either do not use a shift register for error on the while loop, or clear error in the "Error" case, where you are enqueuing the "error" message, so that the Dequeue element can work properly and see this message.

    • Like 2
  3. Anyway, the reason I wanted two means of stopping, was that the program can receive shut down messages from another section of the code and also from the user when they're looking at the front panel. Either way should shut down the code with a single button press.

    You could use the value (signalling) property of your Done Calibrating button to stop the event loop in response to the shutdown message from the other section. That way the same button can respond to the user click as well as outside messages.

  4. Adding a filter for VI state sounds like a good idea. I'll look into it and any optimization for adding large number of VIs to the tree. May be use add multiple items to tree instead of adding each item individually. But during a refresh, it has to get the properties of each VI and update them. Well may be not, if we specify which properties (columns) will change during execution and check only those.

    I'll post an update or list of issues :)

  5. It was the while loop around the event structure that finished execution. The event structure is put inside the while loop so that we can give it a chance to handle more events that might have occurred since its last execution. By not returning control to it, we took its ability to handle the events away.

    I see your point too! It probably should have locked down the front panel once it started handling the event and then should have unlocked it, once it was done. But I'm not sure if this is the behavior we really want. Let's say the loop is busy handling one event and you click a button, which is supposed to lock down the FP. If the FP is not locked down right away, you could generate many other events before the button click event case gets a chance to execute. To avoid this, you could enable locking down FP for the current event. But then, where do you stop? This strategy would have to cascade through all the events, because you won't know when a user might throw in a couple of clicks.

    Ideally, this shouldn't even be an issue because your event handler should receive all FP events and then send them for processing elsewhere. The event loop should finish only when the VI is "on its way out" and at that time, the FP should be not be expected to let you interact with it.

    • Like 2
  6. ... If I start it and hit 'Done Calibrating' more than once the FP won't respond to clicks on 'Stopped? 2' and needs to be aborted.

    Turn off "Lock front panel..." for the Done Calibrating:value change event and this will be fixed.

    When you hit Done Calibrating once, it shuts down the event handling loop. When you click it again, it locks the FP until "this event case completes", but the event never gets a chance to handle this event again and the FP never gets unlocked. That's why you can't click on Stopped? 2.

    • Like 1
  7. Don't forget that there is an invoke node to the String control that can "Get Nth Line".

    Hi MikaelH, we did use the "Get Nth Line" to count the number of lines, but that takes some iterations (and time) to come up with the number of lines and it didn't work for Mark. His solution works pretty well, where he is calculating number of lines from the font size.

    I haven't looked at any VIs in this thread, but if you're not wiring an Inf+ constant for your "crazy large number", you should be. ;)

    The Text.ScrollPos property takes in a U32 number that can have a maximum value of xFFFFFFFF or d4294967295, which is the "crazy large number" that we were using.

    If you wire Inf+, wouldn't it be converted to the same U32 max of 4294967295?

  8. Hi Mark,

    Now I understand what you meant by moving the scroll bar to the end. I thought that this is a case like reading a large body of text and you wanted it to scroll as the user you read through it. I didn't realize it just had to keep the latest text visible, as it was added, if the scroll bar was moved to the bottom.

    Well, I guess now we have two solutions that could help at least two people :)

  9. Sorry about that! When I downloaded Darren's VI, it went straight to my Downloads folder and was being linked from there. I've fixed that now and have actually included it this time :) Here is the updated R5.

    LabVIEW Task Manager R5.zip

    I've added grouping by class/library that you suggested. I've also added a Close FP button and improved the numeric sorting of the data tree.

    Please let me know if anything is missing this time or if you have any suggestions/comments.

    • Like 1
  10. Darren Nattinger had a different attempt to the "find the clones" problem. His solution gets all the statically referenced clones.

    Thanks Darren! I have included your VI in the solution.

    Here is the latest package that include most of what we have discussed so far.

    LabVIEW Task Manager R4.zip

    My experience is that when working with dynamic clones, the count keeps going up on each debug run of the VIs, so you might know but it is easy to lose track.

    After including Darren's VI for searching statically referenced clones, we no longer need to include the Clone VIs FG.vi in the reentrant VIs that are statically referenced. But if you put this FG into a reentrant VI that is called asynchronously, it will make sure all clones are found.

  11. So Mark, how do you AutoScroll when the user moves the scroll bar to the end? If the scroll bar is controlling the scroll position, wouldn't the text automatically followed the scroll bar to the end while you were moving it there?

    I guess adding another button at the bottom of the scroll bar could be more intuitive. Here is what I have so far.

    Number of Lines in String Indicator.vi

    String AutoScroll Main.vi

    Can you send me some sample text that you are working with?

  12. The design uses modules which communicate to each other by messages. The module waits for a message in a subvi and when it receives a message it executes the command in the main vi. My goal is to see how much time is spent waiting on the next message and how much time module spends executing code. If the module is always executing code there is a problem since it will be slow responding to messages.

    You mentioned that the modules are communicating with each other via messages. But have you separated the part of that receives and responds to the messages and the part that does the heavy lifting?

    Since you are concerned about the response time from the module, I'm guessing the response you are concerned about is not the result of this heavy processing that module is doing, otherwise you'd just have to wait for it to finish, unless you want the last calculated value from it.

    The example you shared has a SubVI in a Main VI loop. If the SubVI takes a long time to pass the control back to the Main VI, you should have a different loop in this Main VI that is supposed to handle messages/events.

    About measuring time, it is a good idea to use the Get Date/Time in Seconds to read the current instead of the Tick Count (ms) as its value can roll over during execution, which will throw off your measurements.

  13. Hi Mark,

    I created a VI that will count the number of lines in a string indicator.

    Number of Lines in String Indicator.vi

    The VI below will let you test it out. Currently, when you change the value of the string control, it recalculates the number of lines.

    String AutoScroll Main.vi

    I tried to test it while resizing the control with the pane, but I need to put some more work into it as it doesn't like the conditions changed on it while it is calculating. I'll add that and send you the VI again.

    As for the scroll bar, I'd suggest adding a separate scroll bar as it will give you more control over it and also you can catch the value change event for the scroll bar.

  14. You might want to instead have a numeric control of the cone number to search up to. Zero would mean disabled, the default could be 100 or so, ...

    interesting! I just happened to do exactly that this morning. Great minds think alike, I guess :)

    ...Users could increase the number if they were working with higher-numbered clones.

    Would one always know if he is working with higher-numbered clones? AQ suggested otherwise!

  15. So let's say we have the combo box below, with the mouse clicked on the drop down symbol to show the list of items:

    post-9308-0-76617100-1316709814.png

    For ease and clarity of communication, can you just pop this image in Paint and add some color to show what you want to do?

    Do you want to color any or each item in a different color? If so, it might not be possible to do that with the native combo box. However, if you must have that functionality, we can create a workaround.

×
×
  • Create New...

Important Information

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