Jump to content

Jordan Kuehn

Members
  • Posts

    661
  • Joined

  • Last visited

  • Days Won

    20

Everything posted by Jordan Kuehn

  1. Definitely DSP. I don't know the book MarkCG recommended, but understanding the fundamentals of sampling and signal processing is at the heart of most of the use cases of LabVIEW. Now you can get by with the tools NI has developed for you, but you sound like you are interested in a theoretical knowledge and rightly so! If you can understand the math in a course like this, you've already got most of the more fundamental math disciplines under your belt.
  2. This touchscreen keyboard was discussed a little while ago: http://forums.ni.com/t5/Example-Programs/Touch-Screen-Keyboard-and-Keypad/ta-p/3491341
  3. Shooting in the dark here as well, but I would start with just a moving average at first...
  4. You may have more luck with an RTD and something like this: http://sine.ni.com/nips/cds/view/p/lang/en/nid/201609 I agree the c-series options do not look like you'll get the rate you need. With a transmitter like ShaunR suggested, take note it's response rate and that some/most are not scaled to temperature, just the non-linear thermocouple signal is output.
  5. This should be a bold pop-up for the first 10 times anyone drops a vision VI. Image wires are references.
  6. Looking at the equations suggests to me that the issue is not the code, but the equations themselves. They rely on each other cyclically...
  7. I'd suggest that it is fairly likely that you have at least one of your while loops completely consuming one of your quad cores on the original machine, and your dual core atom processor doesn't have a free core to devote. Look through your different loops and see if one is missing some timing, (e.g. a polling loop that is polling as fast as possible) and add a wait timer to slow it down even just a little.
  8. To clarify some, you will need to create a build specification under the myRIO target in your Project Explorer using your main myRIO VI, set it as run as startup, build, and deploy. Then it should be able to run headless and you can run just the Windows VI. You'll likely need to take into consideration that it won't have anything talking to it unless the Windows VI is running and have it handle that appropriately. I think this will accomplish what you are wanting. You will need to rebuild and deploy each time you change the myRIO code. On a side note, I really want to get one of these to play with at home. They are cool little embedded targets with built-in wifi. Lots of potential! I had a customer a couple years ago that had a few we used to develop some standalone applications that could be interacted with remotely.
  9. Glad you found a solution. The first link I provided outlines the handbrake CLI.
  10. Handbrake immediately comes to mind. https://handbrake.fr/docs/en/latest/cli/cli-guide.html https://handbrake.fr/ https://www.techwalla.com/articles/how-to-use-handbrake-to-convert-a-mov-file-to-an-avi-or-a-wmv
  11. I "helped" with that postgresql question a couple weeks back and got a feel for it. It was a bit of a learning curve, but didn't seem too bad. Most of our active systems use an Access DB and I have a library of tools using NI DCT that I use. I've been playing around with SQLite in my free time and I like what I've seen for local machine applications.
  12. Your VI is missing a subVI so I cannot run it, but you will likely need to use the two derivatives together. The zero crossings of the second derivative will give you the points of inflection as ShaunR pointed out. Use these locations/indices to reference points on the original function and the first derivative. You can likely filter out your segments by looking at the first derivative values and determine which points of inflection are important or are on your curved segement. The value of the first derivative at that point will give you your slope for the tangent line.
  13. Some context. Possible Dup. https://lavag.org/topic/18676-signal-analysis-and-processing/
  14. With minimal modbus experience you should realize that you will need to both configure the Kolmorgen drive to expose and react to the data in the modbus registers and program the LabVIEW code to interact with the drive. Additionally, you are best off using the built in modbus tools in LabVIEW now that require the DSC Module or the RT Module. That said, you can probably accomplish what you need using a low level API that is not officially supported. This will take more work and understanding of the modbus protocol, but is cheaper if you don't have either of those modules. Finally, take into consideration that it is not a very fast protocol and will perform more slowly the more registers you need to access.
  15. I was contacted by our ISR (I think that's still the title) a week ago or so, encountered the same problem, was forwarded to support, and nothing since.
  16. Try encasing the column name in double quotes "user" and using the original query with the = comparitor and the semicolon. postgresql test.vi
  17. Does postgresql require a semicolon at the end of the query?
  18. We have developed a Modbus based control system for a Kollmorgen drive for a customer. It works well and uses ethernet connectivity. I would suggest investigating that to see if it meets your needs based on timing requirements and the control variables that are exposed in the modbus registers.
  19. I apologize, select grayscale. The important part is to have a separate reference, from glancing at your code.
  20. Create a new binary image outside the loop and feed that output as the destination for the output of your vision assistant processing. That should stop the final image from flickering, I think this is what you are complaining about on the output. Image wires are references, not values. The area particle measurement should get you the value you want. What is wrong with that?
  21. It is better today. I tried a few things, but nothing helped at the time.
  22. LabVIEW has been marketed as a complete language since at least 2009. It should be able to stand up to python and such. That said, it's not just NI that is responsible for driving acceptance of the language and moving it out of the niche space. We (professionals, but definitely consultants) are a big factor in driving that as well. Initial costs to develop a system provide a lot of inertia after it is completed.
  23. Awesome. Sorry I didn't get around to advancing things like I had hoped! I will try to look through this and your new goals to see what I can add if I have a chance.
×
×
  • Create New...

Important Information

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