01-14-2016 02:42 PM
So I thought I had this figured out but apparently don't at all.... This is probably a simple fix, but when I update elements in a clustor, I have other elements get reset to default values. Does anyone know why this may be?
For example, I have this clustor shown below with 6 numeric indicator fields, but when attempting to update a single field, the other field is reset to 0.
The first iteration of my program grabs the data and updates the DMM - Resistance indicator as shown below....
After this, I add into the queue to update the DMM Capacitance field in the same format...
And when I update the Capacitance field of my clustor... the Resistance field returns to the value 0.
Is there something I don't understand about clustors, or bundle by name that may solve my problems?
Thanks in advance.
Kellen
Solved! Go to Solution.
01-14-2016 02:51 PM
It looks like it should work, can you post actual code or a snippet?
Also, can you select the case statement in question and press the "Clean up diagram" button"? Not that your diagram is messy, but if you have some weird wiring or objects hiding under other objects it will reveal it.
01-14-2016 03:01 PM
Here is the VI, but I'm not sure how much it'll help. The dependencies won't allow it to run for you but at least you can get an idea of what I'm trying for.
01-14-2016 04:10 PM
The two fragments you posted, showing reading/writing a Local Variable, suggests that you can, and should, use a Shift Register, instead. Try this (there are some things that show "dimly" because I don't have your TypeDefs) --
Notice that (a) Measurement Data is initialized (by the Cluster Constant connected to the input to the Shift Register), (b) the Measurement Data is updated on every change, and (c) there are no Local Variables anymore (generally a Good Thing).
Bob Schor
01-14-2016 04:18 PM
Well you still left a Local Variable there in the Case Statement. Can that be removed?
01-14-2016 04:23 PM - edited 01-14-2016 04:25 PM
Yes, of course -- I meant to delete it. I did delete it in the other Case, I think -- this was just carelessness on my part, sorry ...
BS
01-14-2016 04:56 PM
So I have made the changes, and the problem persists. It's almost as if the data flow isn't working properly. It just doens't seemt want to update the indicators when it's being told to... 😞
01-14-2016 05:42 PM
Can you post the typedef control for that particular indicator too?
01-14-2016 06:01 PM
So, I simplified what I was doing, removed the state machine, and now it works fine. Not sure what the hang up was, but it seemed like it was going into a wait state before it was finishing the update on the indicators. So I'll see if I can just stick with the simplicity and make it work. I have attached that type def if you want to look further into what I was doing wrong.
01-14-2016 08:08 PM
@rkmadse wrote:
So, I simplified what I was doing, removed the state machine, and now it works fine. Not sure what the hang up was, but it seemed like it was going into a wait state before it was finishing the update on the indicators. So I'll see if I can just stick with the simplicity and make it work. I have attached that type def if you want to look further into what I was doing wrong.
1. No need for that local variable inside of the case structure. The indicator will update with the next loop iteration thanks to the shift registers.
2. You had a weird state machine going. What you have here is A LOT easier to understand. You just now enqueue all of the states you want to go into and in what order. If you get an E-Stop condition, use the Enqueue At Opposite End to make sure that is caught immediately.