I am in the final stages of wrapping up the first release of a custom node. I have been using it in development for a few months and think it is stable and useful enough to release for others to use. I am always using the most recent version of Node Red on my machine, so I am not sure what to put for node red version compatibility in the package.json.
If anyone has any input on how to determine version compatibility other than unit testing on every previous version I would appreciate it. Also if anyone wants to take a peek at the library and give me constructive criticism I am open to that too, keep it mind that it is not 100% polished yet - the examples may need to be updated, the documentation and property names may need tweaking, and I haven't written unit tests yet.
A minor detail, you have the repository url wrong in package.json
Make sure you test it with all the supported versions of nodejs (14, 16 and 18)
I don't know what to suggest about node-red versions. Looking at the code it doesn't seem to have anything that is going to stop it working with any version of node red.
Is it not possible to pre-configure PID constants in the node?
There doesn't appear to be any help text.
It is a good idea to provide one or more example flows that can be imported from the Import > Examples menu. It isn't clear to me exactly how to wire the nodes up.
I see you haven't used Typed Inputs. Those are to be encouraged wherever practical.
Ideally you should provide a proper license.
What advantages do you think your node has over node-red-contrib-pid?
Ok, that was my thought too, I will do those tests.
Right now, I don't have that option because when using the Autotune companion node or if setting the tunings from another node or a Dashboard element, the editor would not show the updated values, so on a redeploy it would overwrite the tunings.
Good catch on the help text, I will work on that. I do have example flows, but maybe I don't have them setup right in the repository to automatically show up in the Import > Examples menu, I will have to look into that.
I do have an MIT license file in the repository - the two nodes include some code that is ported from other libraries, so I have to include those licenses as well. My license file states what sections are licensed code and licenses all of the work which I have added, the other two licenses are included in the Licenses folder because I have to supply them with redistributions of the ported code. I guess I don't understand what you mean by "proper license" as I thought that that is what I have done.
I think quite a few actually. When I started my project I tried to use that node and I found it hard to use and I found the behavior erratic, I also prefer to tune using Kp, Ki, and Kd and that library uses Kp, Ti, and Td. This library adds optional persistent context storage, allows bumpless changes to tunings on the fly, and incorporates the Proportional on Measurement and Derivative on Measurement functions. The main PID calculation code is a port of the Arduino PID Library which has been ported into many languages (e.g. Simple PID in Python and others) and is bulletproof. It also has the companion autotune node which is similar to node-red-contrib-pid-autotune as they are both ports of the same parent library, but mine is specifically designed to interact with the companion PID node instead of making the user manage that connection manually.
Again, I really appreciate you taking the time to look at the repository and provide your feedback. I will incorporate those changes when I work on it again tonight.
If it was behaving erratically then I would very much like to know about that, there have been no reports of that from others, and I have never seen it myself. I see you did not report an issue about it.
I would be grateful if you could describe what the difficulty was, as I am always keen to improve the documentation.
That is a matter of personal preference obviously. There is no right way but generally I have found that engineers (as opposed to mathematicians) find it easier to understand the time based parameters as they have some meaning in the real world.
Yes, that is a potentially useful feature. I might think about adding that, though I am not certain how important it is. Controllers generally are tuned once and then spend the next several years just ticking away, so it is not a feature that is generally useful once the controller is in a 'production' environment.
I understand the option for Derivative on Measurement (that is what my node uses by default). Have you come across much demand for Derivative on Error?
What do you mean by Proportional on Measurement?
Well if you are looking for pedigree, then the algorithm in node-red-contrib-pid was first written in assembler for an 8 bit microcontroller for the first generation of digital industrial process controllers in 1982. Before that, controllers were analogue. It too has been ported into many different languages over the forty years since then. I like to think most bugs have been ironed out over that time. Though, obviously, any port port potentially brings its own new bugs initially.
I haven't tried any of the autotune nodes, I will have to give yours a go.
It is very possible that this was just me, and I'm sorry I didn't realize I was responding to the repository owner when I replied before, I found when I first started using it that I could never get the output to settle and it was constantly jumping all the way up to max and then all the way back down to min with the integral not really holding a value for more than a few seconds. It was probably user error, but at the same time I was learning node red and frustrated so I spun up my own simplified version with the ported Arduino library and it behaved like I expected, so I just ran with it and continued to build it up and add features as I needed them. Like being able to pick any arbitrary range for the output instead of having to put a range block after to convert the 0-1 to your system's units or to invert the range for heating/cooling.
Not much use for DonE to be honest, but there are applications that don't like DonE. Most of the commercial PID implementations I have used provide the option for both and letting people have the option to do one or the other with the default being the more common DonM was an easy implementation.
Proportional on measurement is meant for integrating processes - in self-regulating processes a given controller output means a given PV, in integrating processes you have to increase the output to get to the new PV then drastically cut back on output to maintain that value. Without PonM you have to overshoot the target to bleed off the extra integral term that was acquired when the SP changed. PonM is a method, for some processes, which helps avoid the overshoot by changing the action of the Kp term to a resistive term proportional to the change from an initial stable setpoint. You can think of it as an Integral dominant controller that lets the I-term for an integrating process function more like a self-regulating process. http://brettbeauregard.com/blog/2017/06/introducing-proportional-on-measurement/ Worth noting that that is the one feature I have not tested in my node yet.
I wasn't trying to make this a measuring contest, sorry if it came across that way. I had to come up with the elevator pitch for why someone might use this over the incumbent node.
The autotune node is a port of another existing library and it seems to work really well - I have used it to autotune my brewing setup and it does a really good job of keeping an accurate temperature. It is specifically meant to pass messages that work well with the companion Autotune node, but it could be adapted for use with others by putting a function block in the middle to sanitize and repackage the control messages for the other node. Node-red-contrib-pid-autotune is a port of the same parent library, although I haven't tested that node in particular.
