Jump to content

infinitenothing

Members
  • Posts

    354
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by infinitenothing

  1. I'm not sure you can do what you want to do with the XY express VI. You need to make an array of XY bundles as shown below.
  2. Double click the "Build XY Graph" express VI. Uncheck clear data on each call. Also, you don't have to subtract 1080 or 720 from each x,y pair. You can just click on the top most number on an axis (eg 720) and enter in 0. That will make it so that small y values are plotted at the top.
  3. Is there anything preventing you from moving the graphical objects around? There's some property nodes for that. As for the z-order, you can vote for that here: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Programmatic-Manipulation-of-Object-Layer-z-order/idi-p/1262886
  4. I thought it was a bit vague in terms of what you want. You want another UI theme in addition to classic, modern, and silver, or something that's more evolutionary like NextGen?
  5. To the rest of us out of the loop it's just spam though
  6. How did your program exit? Did the enqueue timeout? If not, the rate is probably limited by the camera. If so, your rate is limited by your disk. Are you using a laptop? You can get an SSD for <$300. How big did you increase the queue size. If you use 64 bit labview and have tons of memory, you should be able to store all those images to memory. Actually, how are you benchmarking your frame rate? I would benchmark it in the top loop and output the delta t to a chart so you can see if it goes fast while you are using memory.
  7. There's no advantage in the lookup case. That was just to show syntax. The advantage in the increment case is the same as with the other IPE border nodes. It provides a cleaner syntax and, if the child variant is large, it might improve performance by avoiding a copy.
  8. The variant on the inside is referencing the child's data. The author wants to add the new attribute to the parent variant.
  9. Here's an example of using producer consumer. If you have a solid state hard drive or a RAID disk, something like this should work. You'll notice there's two places we're storing images in memory. The "number of buffers" and the "max queue size". In this example, we'd primarily increase the max queue size to store more in "RAM". IMAQdx already decouples acquisition for you so another option (not shown) is to increase the "number of buffers". While you were saving the image (where the enqueue is now), IMAQdx would be filling the next buffer in parallel. The only caveat is that IMAQdx uses a lossy buffer so you would have to monitor buffer number out to make sure you don't miss any frames.
  10. Your reference id: 0x496d6167 is hex ascii for "Imag". That is, it's the first four bytes of your image name. Images are string references a bit like a named queue. It's too bad Image Refs came before DVRs. It would have been much simpler to understand if you knew the DVR syntax.
  11. Good tip! My ROI tools (just the selection and rectangle tool) still look ancient though. It's fixable but I was hoping someone else did it first.
  12. Does anyone know of a flat style imaq image display? All the image displays from NI are either submarine colored or have dropshadows from the last decade
  13. I'm not totally clear. You said IMAQ cast is working. Are you trying to reimplement IMAQ cast?
  14. Looks like it could be a good solution for these ideas: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Integrate-Start-Asynchronous-Call-with-Static-VI-Reference/idi-p/3307187 http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Asynchronous-Call-By-Reference-with-Strict-Static-VI/idi-p/1662372
  15. I'm not sure why the idea exchange mods didn't understand how powerful it is to be able to generate a case structure from a "class". The primary advantage being that you can put terminals,locals, and front panel linked property nodes in a case structure but not directly in a subVI. That can make things easier to debug because, from the front panel or from a terminal, you can "find all.." for those. I feel like they are stuck on OOP as a one size fits all solution.
  16. The reader will be using minimal resources while it's waiting for a new message so there's no need for additional breaths. I still think you need see where the extra messages are coming from by creating very well known unique messages. Also, your error handling in the reader terminates at the RT FIFO so I don't think you're catching errors (which seems like a likely culprit at this point). You can "OR" in the error and the timeout from the read to make sure you don't go processing invalid messages.
  17. No, from the application level, I don't know of a way to see how many elements are in the buffer. It's unusual to leave anything on the buffer with TCP. Normally, you read as fast as possible without any throttle. You can then implement your own buffer in a queue for example. Then you'd get to use the queue tools to see what's in the buffer. I think your problem points to an application issue where something's writing faster than you think or your reader isn't really reading. Maybe it's throwing an error or something. What do you think about my "unique data" idea. You could slow the server down to once a second and just send 1, then 2, then 3. You should see that show up on your client. Also, you might want to post your client code.
  18. First, calculate how long it's been since the last encoder event. Then you need to latch that number when there's a new event to get the period between the last two events. What you do with the period from there is highly dependent on your application and available resources. If accuracy is of utmost importance, you can store all your periods in a FIFO and then integrate to get times and apply a quadratic fit to get the velocity and acceleration.
  19. Yeah, what you're describing doesn't make sense. You can't have a server send 82 bytes every 10 ms and have a client receive 82 bytes every 1 ms. Maybe have the server send unique data and verify the messages at the client to see where the extra data is coming from. This won't fix your problem but, I recommend replacing the timed loop with a while loop. TCP code in a timed loop makes no sense to me.
  20. Look at the hex. That will show you how they flatten differently. I don't have LV10 so I can't test.
  21. It's weird behavior for a weird use case but it appears to do what it says it's going to do. https://zone.ni.com/reference/en-XX/help/371361M-01/lvhowto/case_selector_values/
  22. Can you examine the binary flattened string to see the differences between how LV14 would flatten the string vs LV10. You'll need to change the string indicator type to show hex. I can tell you it's a little unusual to flatten a variant. Much more common to flatten what would become a variant and then use that as a string in the flattened cluster. For example:
  23. I wouldn't say there was a big risk. If you find out 64 bit isn't going to work, you can always just install 32 bit next to it and switch over.
  24. What sort of jitter are you seeing? What were you expecting? How much can you tolerate? If you have to have better jitter try: Move the indicators outside the loop. When you write to an indicator in development mode, it needs to use the network. You might also want to move the controls outside too and use something like a single process single element RT FIFO shared variable Turn off debug Replace the while loop with a timed loop
  25. Ensegre, don't you need a convex polygon for that? You could convert the vectors to discrete pixels using Bresenham's Algorithm
×
×
  • Create New...

Important Information

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