Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/26/2013 in all areas

  1. I can do without extra event structures as long as we get an event structure that we can wire TCPIP,UDP, Bluetooth and VISA refnums to.
    3 points
  2. A single catch-all Event structure is a recipe for increasing the coupling and decreasing the cohesion of your code, we must have different metrics for maintainability and readability. That is a double-whammy in my world. I have my own icon editor which has been a systematic refactoring of the shipping version. Step 1 was converting the single ES to a group corresponding to the different tabs. Now tabs can come and go as I please. You may prefer to get slapped in the face when you click on the Event selector label, I say no thanks. And the timeout is so much more useful with a restricted set of events. I can have multiple time scales very easily.
    2 points
  3. All, I am happy to announce that I am back in blogging on ExpressionFlow. I'm trying to cover more theoretical topics around visual programming and discuss new fresh approaches. I'd like to invite everyone to follow the blog and @expressionflow twitter account. url: http://expressionflow.com twitter: @expressionflow facebook: https://www.facebook.com/expressionflow Please let me know the kind of topics you'd like me to discuss. There's lots of cool topics on my mind already but I would love to hear from you, what would be something interesting for you all. Thanks, and happy Thanksgiving for everyone! Tomi
    1 point
  4. You can use the Project API to find the Target Item and then modify its properites. The project is technically an XML file so there is a method to get/set tags for targets. The tag "alias.name" is the RT Target Name visible in the project. The tag "alias.value" is the IP address as a string. The attached code modifies one of the RT example project IP addresses programmatically. Set_RT_Target_IP.vi
    1 point
  5. I can only guess based on the help, since I generally use pure SQL syntax... The update statement will try to update all columns in your table which is impossible as you need a primary key (a column that is the unique identifier). This would be 'speedo_ok' in your example I guess. You could now either update element-by-element using the condition input WHILE speedo_ok={speedometer values.select} where you have to replace {speedometer values.select} with the actual value of the particular element. The second option is to present a new primary key to your table that is set to auto-increment; and always define the column names for your cluster whenever you use the cluster to insert / update / etc... The update statement with all cluster elements makes no sense as far as I understand, as this would cause all rows to carry the exact same information for each column. As I mentioned before, you need a primary key that is unique. Try to update a certain element of your cluster using the condition I mentioned before. Maybe someone else could give an actual example how to solve this based on the DB VIs? No problem, I had to learn all that stuff too A good source for SQL has always been http://www.w3schools.com/sql/ or MSDN of course for MSSQL. Just for my own satisfaction , but this would be the SQL syntax (I did not test it, but it should work): You have to replace all elements in {} by their representatives in the cluster. Green would be valid, red is what you try to do (I still assume speedo_ok is your primary key): UPDATE speedometer SET speed={max speed}, frequency={speedo max freq}, amplitude={speedo amplitude}, pulse_rev_n={speedo pulse/rev}, ratio={speedo ratio}, pulse_type={pulse type} WHERE speedo_ok={select}; UPDATE speedometer SET speedo_ok={select}, speed={max speed}, frequency={speedo max freq}, amplitude={speedo amplitude}, pulse_rev_n={speedo pulse/rev}, ratio={speedo ratio}, pulse_type={pulse type}; I hope that helps.
    1 point
  6. Somewhere in the dawn of the ES (6.1? I think), while wrapping my head around this great new paradigm, I took it as a commandment that THOU SHALT HAVE NO MORE THAN ONE EVENT STRUCTURE PER DIAGRAM. I've frequently been appalled by the code of some of my coworkers who blithely put down 2, 3, or 4 ESes in separate loops. (Heck, I don't even like to have more than one ES in an entire execution hierarchy, maybe I'm carrying it too far?.) So it wouldn't bother me. But I am curious, AQ, if you went ahead with this enforced limitation, what kind of upgrade mutation could possibly save such (IMHO, barely maintainable) code that's out there? Dave
    1 point
  7. Especially as he marked his answer as Best Answer" to his own question. Now. Where are all my posts .
    1 point
×
×
  • Create New...

Important Information

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