Watlow F4 Profile Programmer

[Cannon_Controls]

Also, here is what I have as far as a profile generator. From here, would I just bundle up the things that go together and then flatten to xml?

[Cannon_Controls]

Actually, I made a few little tweaks there. This is what I have so far. Just not sure how best to log to the xml file from here. 

[billko]

Sorry I didn't get back to you sooner.  Yes, that could work.  I don't think you need to enqueue at opposite end, though.  I'm pretty sure you can use a regular enqueue instead.

Looks like it's shaping up.

[Cannon_Controls]

So, in this case, I am bundling the command to be queued and the values associated to that command. From there I want to use the flatten to xml VI on the cluster. From there, I want to use the concatenate string function to combine the strings and then connect that to the write to xml file VI. What would be the best way to make this work as I don't know exactly how many steps there are or the order of those steps? I can figure out how to flatten each step to xml but then for the concatenating strings, how would you do that? Or would you just auto-index all of the clusters and then write the array to xml? There is what I have.

[Cannon_Controls]

So would something like this work?

[Cannon_Controls]

So here is what I have so far and it is writing the clusters to an xml. Now I am trying to write to a table as things are clicked and am having a few issues. For some reason it always writes an end command at the start of the program. Do you know how to prevent that? Also, it is often writing double of each command. For example if I click ramp rate it will post ramp rate and then if I click soak it will repost ramp rate another time before posting soak. The time is writing at all but that's because it's an array so I was just planning on converting the array to minutes and then publishing that value as an int.

[Cannon_Controls]

Actually, disregard that. I got it working. I just needed to move my enum control. Seems to be fine now.I will work on reading the xml file in the other program now and if I have any trouble, I will let you know. Thank you!

[Cannon_Controls]

I am having a hard time seeing how to implement reading the file now. So on startup I have the read from xml VI. I have selected to read an array. From there I have an index array subvi to seperate the different clusters it's reading. The problem I am seeing is that there is an undefined number of clusters and the clusters contain different things inside of them. What is a good way to read any number of clusters with any combination of strings, numerics, or arrays in the cluster? There's probably an easy solution to this, I'm just missing it as I've never done something like this before. Again, I really appreciate your help with all of this. It's finally coming together and getting close.

[billko]

I'm so sorry I've been neglecting this topic.  I've been working 12 hour days the past few days, and I don't have much time to do anything.  Let me think a little bit...

[billko]

Okay, here's some advice code-wise.  Your stop button should have an event of its own.  It should enqueue a stop state and the stop state is what tells the consumer loop.  (What's the QMH equivalent of consumer loop?  I don't know, so I'll just stick "consumer".)

Also, there a re things you need to do.  Some are more important than others.  Enqueue Opposite is going to get you in trouble if you anything even remotely more complicated than this VI.  The problem is, Enqueue opposite puts your data as "next in line" to execute.  When you have a queue length of one, "first in line" and "last in line" are the same thing.  More complicated VIs may have several items waiting in the queue and having someone jump the queue to be next in line could have disastrous effects.  Best to get into good habits now.  🙂

Another good habit to get into is to create default values for your shift registers, unless the situation calls for it not to.  (And if you don't know what that situation is, you don't need to know about the usefulness of an uninitiated shift register.)

Nice-to-haves:

Instead of having your states be strings, have them be (typedef'd) enums.  That way you don't have to worry about spelling (except for aesthetics, of course), and whether or not you have a matching string for each state.  If you've removed the "Default" state, every time you add a state, the state machine breaks because you need to make a case to go with the state, so it shows you where you have to update your code.

Even better:

Enqueue a cluster containing the state enum, and your data (as variant).  Dequeue, unbundle before your case structure.  I think you can guess the rest.

Attached is your VI with a few small mods.  Deleted the timeout, moved the Stop terminal into its own event case, enqueued the stop state.  Replaced Enqueue Opposite with a regular Enqueue.

As for your xml file, I've been thinking about it in the same way as you.  It might be simpler to save it in a config file, instead:

[Command01]

Command = "Soak"

Parameters = "1,2,3,4,minutes"

[Command02]

Command = "Ramp"

Parameters = "5,6,7.5,8,9,10,seconds"

When creating your array of commands, you suffix [i] onto "Command" to get unique section names.

Parse "Parameters" as a comma-delimited string to get your list of parameters.  (You'll have to remember what each parameter is on your own.  This is a drawback.)

I hope this gives you ideas!