Watlow F4 Profile Programmer

[Cannon_Controls]

That is all very helpful and I appreciate your advice. I've honestly only ever really used the enqueue at the opposite end and wasn't really aware that it was placing things as next in the queue. I've only ever really made simple programs so it hasn't been an issue, but that is good to know. So in creating the config file, I should bundle the parameters as I have been but also add [i] to the end of the command? Does the command need to be at the top of the bundle then? Or does it just need to be in each cluster somewhere? Also, I am currently using LabVIEW 2017. Is it possible for you to save a 2017 version of the file that you attached?

[Cannon_Controls]

So I've updated the profile generator program to write to a config file. Is this how you would imagine this working? I've flattened the cluster to a string and then have a for loop writing it to a file. I concatenated the command with the [i]. 

[billko]

Sorry, I misled you about [i].  This is what I meant:

 (I know this in LV 2020 - didn't have earlier version to make the snippet.  Sorry.)

[Cannon_Controls]

If you saw my last message, you can disregard it. So here is what I have so far. It is all working correctly other than the fact that on the first two steps under the first key and set of parameters, it's including an extra "end" key. I don't really know why it's doing that. I have it writing "end" only when the abort message is sent by pressing "Save Graph". I don't think it's critical, I could probably just ignore those messages while parsing the data I read in the other program. Not sure if you know what could be causing that but I will try to figure it out and get working on reading the data in the other program. Also, I wasn't able to download your tweaked version of my other program as I have LabVIEW 2017. Could I get you to upload an older version. Thank you so much for all the help.

[Cannon_Controls]

Here is what I have as far as reading the data in from the INI file (I had to delete the extra "ends" for now.) So I have all of the sections, keys, and values. Then I divided up the values seperated by commas. Would you then bundle up the command with it's values and pass that on to the main function?

[billko]

All I ever get is:

[Command0]
End = ""

No matter how many steps I enter.

BTW - It is highly unlikely (read: impossible for a human to do) that selecting the name for your file will ever influence your save path because it only ever executes once.  Unless you are quick enough to type in your name before the control gets read (like I said, "impossible for a human to do") you're stuck with whatever was in there when you started the application.

[Cannon_Controls]

That's weird. Mine was writing the other commands like the one that I posted on here. Now mine is only writing "end". I must've changed something accidentally. I'll look into that. Also thank you for the advice on the control. I considered adding a subvi at startup that asks for the bake name. I'll think about some other ways to do that as well.

[Cannon_Controls]

So I have it working now. And I'm able to read it into it's own arrays fine. I'll work on queuing the commands up and then unbundling the parameters now.

[billko]

I'll take a look at the code when I get home, but it's so cool to see it evolve.  🙂

[billko]

The reason why you are seeing what you are seeing is because you are appending your new stuff to the config file.  I don't believe this is your goal.  I believe you want the new profile to overwrite the old one.  In that case, you need to delete the old file in the initialize state in addition to what you are already doing.

An observation:

In your sequence structure, you have all your property/invoke nodes' error wires wired to a "Merge Errors" primitive.  This is actually an excellent way to ensure that all those nodes execute before everything else.  In fact, it's so good that you no longer need the sequence structure!  I usually reserve this kind of dataflow control for parallel executing subVIs.  For init stuff like this, it's okay to have the properties floating around freely inside a sequence structure because you really aren't expecting errors coming out of your property/invoke nodes.

One more observation:

You are now certainly experienced enough where I'm going to take you task for sloppy coding efforts.  Keep wires straight, keep things lined up in some kind of predictable way.  In other words, follow LabVIEW best practices.  This is not me being anal.  This is me making you make it easier for whoever it is that will need to modify this later.  (It could be you.)

Imagine if you were coding in C and you had random indents.  The compiler wouldn't care, just like LabVIEW could care less about sloppy coding, but if the developer who had to modify your code wanted to know who it was that wrote it so they could go murder him/her, I'd just point to your cubicle, put my headphones on and turn the volume all the way up.