Jump to content

ensegre

Members
  • Posts

    549
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by ensegre

  1. Right. But then one could argue, is it really important to evidence where the mouse has been clicked, or just how the resulting array differs at all? One workaround I could think (maybe), is the following: make an array of clusters, [ordinal,your_content], where "ordinal" is a flag, for example an integer which defaults to -1 and is set to the element number by the Value Change event. In the GUI you could hide "ordinal" if it falls in the way. Then finding the insertion translates into finding the first -1 in New Value, finding a deletion means finding a jump of 2.
  2. What I normally do is to compare Old and New Value and look for the first nonequal element. If the new element is added at the end of the existing, off the head the boolean array will be short as the Old, but the increased length will asess the change in the last element.
  3. possibly relevant? (besides perhaps just projecting the text more into the direction of the observer, out of the solid)
  4. For that, divide the continuous acquisition in chunks, say of ~100ms worth of data, and care for accumulating the data in some buffer or array as time goes on. That way an user event can be processed at the first available slot, before the acquisition completes. The completion of the 2min worth can be tracked with a counter of chunks. As said this is something you control very well if you use the elementary DAQmx blocks, I'm not really familiar with these Express VI signal thingies and I generally avoid them. I don't really understand what you mean, and I can't get into every detail of your coding. At first sight, though, perhaps you should think more in dataflow terms. For instance, your code seems to acquire only once before the event structure; the signal on the output wire is not going to change before the next iteration of the outer while loop (2min?). I don't understand therefore what should happen in the inner while loop in the Acquiring case within the Timeout event. Why do you need an inner while? And why at all a case structure in the timeout event, which redoes and interferes with the way state changes are dealt in other events? I didn't look too carefully at your code, though, nor attempted to run it.
  5. Rambling on my recurring need for backsaving (e.g. quick fix of an old vi on a deveolpment machine with newer LV, deploy on some older LV), and academically thinking at whether someone had already bothered delivering a tool for mass backporting VIs/llbs/projects etc., I ran into these, for the record: Save an LLB to the Previous Version of LabVIEW Programmatically Save VIs for Previous Version list of LV versions backsaving to which other previous About this latter, I wonder if there is some property working in an arbitrary LV version, providing the list of previous versions for which backsaving is possible. Also: a typical clumsy conversion case for me is the following: two main VIs using several but partially distinct subvis from a given reuse llb, need to backsave both, I start with the first and forget that the resulting backsaved llb contains only the dependencies of the first main and not of the second one. And, anyone still remembers the catastrophic bug crashing LV when backsaving anything containing an event frame? I think it was 8.6->8.0.
  6. vormessung c.vi of course.
  7. This could be, schematically, one way to do that. To you to write proper code for each action, of course. I'd recommend to use true DAQmx VIs rather than these Express thingies and separate Create Task, Start Task, Read channels, Stop, etc. That way you can keep the DAQ task open across states, and repeat only the read on demand. vormessung c.vi
  8. If you have already an idea of the state machine, you're already well set for a start, you have just to see one by one the programming details of the subtasks you need to implement. In general I could suggest: -look up examples and get accustomed to the basic operations (e.g. create DAQ task/acquire continuously/graph data/save data), even in a run-once example. -spot out if there are tasks which need to run concurrently in your construction, like e.g. processing or graphing data while more is being acquired, react to GUI events while processing still goes on, etc: these need separate while loops, and a way to communicate data between them (as simplest, local variables; more structured data queues, producer-consumer model,... different solutions with different merits) -learn and define which tasks need a setup which is carried on to every other state of the machine, e.g. definition of the DAQ tasks, and how to carry the information from one state to the other via shift registers. Similarly for properly closing resources on stop/change of configuration, etc. Event structures are not difficult - you just drop the frame inside the while loop and decide whether you need a timeout action or not. The easier events to be grasped are those generated by a GUI action, e.g. the user presses the save button, a Save button Value Change is generated, and the relevant code in the frame is executed for that iteration of the while loop.
  9. Indeed, now that you remark, I see a couple of relevant threads there: Automatic Build System for LabVIEW What is your CI Toolchain?
  10. Anyone using, are there recommendations or tips to share? Following to my whines for a serious internal SCC, I got my IT to install Gitlab CE on an internal server, and I'm happily tucking with it so far. I see that Gitlab should have a product called Gitlab CI (continuous integration) as well as the option of webhooks to external services, I wonder what else it would take to have the functionality working, with private availability of the build. E.g. which build script, where sits LV, cross-platform builds if relevant, periodicity of the build (every commit? nightly? tagged? only last?) etc. General pointers to how automated builds (specifically LV) are handled by other SCC also appreciated, for my education.
  11. I'm trying this technique which is the simplest, but I'm finding really difficult to achieve correct alignment between the rectangles (in LV2014 linux). Moreover, once I drag the control on a FP, the result morphs to an unpredictable container size, with arbitrary displacement between the two rectangles - sometimes one of them not even clickable. When I edit the control appearance, depending on the mode I am into (wrench or tweezers), I note that there seems to be some sort of containing frame, appearing as dashed if I select an area around the control, which encloses the button rectangles in all of its possible states - but the relation between the two button rectangles I can resize, their relative position, the frame, and the result once used in another FP is a complete mystery to me. Are there known bugs, is perhaps the idea of different sized boolean images something which sneaked through the cracks of LV, but isn't really supported? I note that while for instance there are properties supporting the four colors and four strings for all states of the button, there are only one Button Size and Bounds. Attached my simple attempt: it would be a rectangle of about 135x35, half width when off, derived from the Classic Flat Square Button. Well, just resizing the on and off state rectangles, not dragging in anything from the decorations palette. LeftNumberCoveringBoolean.ctl
  12. I would first of all look at which hardware are you going to use. A stepper motor? They usually come with controllers, and you talk to them for instance with simple VISA commands. A DC motor with a set of range microswitches to understand the floor at which the elevator is, whether to open doors, etc? Then you'd need a current driver for the motor and some digital ins for the switches. Something else? DAQ, is there something analogic? Arduino: do you need software to run embedded on it, or can you leave all tasks to the host, so that the arduino would just be a DAQ alternative? On top of that VI logic. Transfer function? In the terminology I'm familiar with that has to do with the frequency response of a linear system; for an elevator?
  13. All interesting ideas, hats off! Can't really mark four or five posts as the Solution, do I?
  14. How can you make a boolean with size depending on its value?
  15. yeah, that gives a better experience. The price perhaps is that the focus condition has to be continuously polled in the timeout case, but its impact should be negligible. EDIT: I see that it works because the editable value read is exactly that of the current element of the array, i.e. that containing the string which has currently focus. I would not have thought at once. I'm afraid that, besides requiring the position to be continuously polled, it will identify the element only as long the mouse is on it. Or, at least as long as it is detected that focus entered to the string (following a mouse click). But tabbing, etc... In any event, thanks everybody so far for the suggestions.
  16. thanks, but that is what I meant by Extending, I could also think ahead at pseudo-disabling mouse-operated controls, like booleans or menu rings; for them indeed trapping the mouse down (and working out the coordinates) should be doable.
  17. Cool, I need to study it. As you say, it may be that the infrastructure needed overwhelms the benefits in my use case.
  18. Right, that is an idea. But how to identify the array element? Key down doesn't return coordinates which can be worked out, and Array, unlike table, doesn't have a property which returns EditPosition.
  19. For a GUI I'm doing, I find myself wishing for something like which notoriously is not possible per element, as array element properties (e.g. disabled) apply to all elements. On the other hand, the array container is soo convenient because it's growable and indexable at runtime. Can someone share an idea of implementation? I've been thinking: programmatical rewrite of the content of the "uneditable" elements which are changed (bad, it gives the user the impression that content could be written into); placement of a fixed maximal number of replicas of the element cluster on FP, and visibility of those needed (will become inconvenient for large numbers); array of clusters with subpanels (no goer). Actually my customer is suggesting something like which would be easily realizable (input field is copied to result on Value Change for editable elements, blanked for uneditable), but I find it a little overbloated, if it has to be extended to more cluster fields. Moreover both Enter and Focus off cause Value Change, unless they are trapped and treated...
  20. Right click on [3] "Play video", "Record Button" Value change -> Edit Events Handled by This Case. What is the word Homework in the title of your window?
  21. you have "Lock panel" on in handling your event case?
  22. without seeing your code, no. My guess would be that, if you're following the usual way of the IMAQdx example, that is register a dynamic event for frame done, and handle completed frames with an event structure, your webcam is generating events faster than you can handle/the front panel is locked while you're handling that event or something the like. I remember having seen a number of webcams/usb,firewire,Gige genicams generating two events per frame rather than one with this scheme, for reasons I never understood.
  23. So, after hours trying to pinpoint an UI bug, I've narrowed it to this: I have a main VI inserting a subpanel and calling it like this while the supbanel may decide to change the tip strip of one of its controls: It's obviously pointless to rewrite the same property every 100ms, that was the unspotted mistake of my original UI. Skipping whether that was dumb or not, here is the weird fact: if the tip strip property is written, cut/copy/paste into any of the subpanel controls using Ctrl-C/X/V won't work, no form of them (all content, selection, at the insertion point). Only Shortcut Menu/Copy Data & Paste Data work, on the whole content of the control, and, in linux, 2nd-button mouse inserts regularly the X selection. If, say, text background color is written instead, copy/paste is ok; I didn't try extensively other properties. Can this be called a bug or is it just a worthless idiosincracy? I've tested these snippets on linux, but observed the original bug which led me here on windows as well. SimplePanel.vi UncopiableContainer.vi
  24. Note taken, thanks. In defense of llbs I can say: they are fit for me to unclutter small scale projects (up to a few tens of vis, SCC secondary), which are to be deployed as main.vi + ancillaries packed in a single place, when the development environment is anyway present on target. That is our common use case in the academia. We have a blanket license and don't mind installing the extra copy, lifetime of software may be very short (three days till the student realizes that he wanted something else, or that the measurement has to be performed differently), need for maintenance and adjustments onsite are a constant, and instruction is often part of the game. And plain llbs don't need a project.
  25. At the risk of saying something obviously off mark, couldn't be that displaying the extracted numbers in FP indicators is the real bottleneck? (especially if you have a weak video adapter)
×
×
  • Create New...

Important Information

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