Saxony Thermal

Thank you! I will study this.

Also to your note about 16 or 32 bit results, if it were 32 output it should strongly affect my other arithmetics who rely on that device that may get unintentionally modified. But all my arithmetic results are accurate, just having this sweeping zero... But respecting your thoughts I did the following and I find this to be an acceptable solution. Originally I was using D100 as my buffer to do calculations before sending the final result to d121, for example, via the arithmetic output. If the arithmetic still outputs 32 bit then it captures D122 which is my next analog input result that I don't want to have messed with. So lets back up the buffer entry to D99 so it has D100 to claim making a 32bit buffer (because D101 is one of my raw analog input devices). I then have all arithmetics for all my analog input readings dump into that 32bit buffer, and then add a new MOV step to move just the D99 16bit info to D121. Attached is my new working code. This eliminate my sweeping zero issue. None of my calculations break past 16bits but it is apparent that the arithmetic is 32bit output despite the documentation saying 16bit and was 'capturing' or 'freezing' or 're-initializing' the 32bits to 0 before doing arithmetics, and my sweeping zero was the second byte of that 32 bits that I would see in my HMI. So had my calculations overflowed 16bits, it would probably had shown non-zero instead of a sweeping zero. I supposed my outputs were also always accurate because there was always 0 in the second byte of the arithmetic. If it were non-zero then my other arithmetics would feed in that value and go all bonkers. But zero kept them level headed.   I still, totally, ignored labels in this solution. If you have good documentation or youtube videos on applying labels that would be much appreciated. Otherwise I will keep doing what I know best which is all devices. I spent a good hour trying to figure out the labels but it was fighting me really bad.   Otherwise, thanks very much!! You helped a lot.

I mean, I can get it to change errors doing various foolish combinations of data type and array sizes, but this is not too productive because I don't know what it is asking for. It eventually just says the data type doesn't work with the device. I have been looking around on youtube and am surprisingly not finding any explanations on setting up arithmetics with labels...

I did find an Array Element option when configuring the label type, but that did not resolve the error adding a second element to the array.

I am using labels now, but please be skeptical of my application of them. I have never used labels before. I get an error when I convert saying to specify an array label of '2' elements or more to the label being used. I attached an image. I'm fiddling with it to try to make it work unless you know what that's all about? The documentation doesn't seem to share what this error means. In C I would assume it just wants me to make an array of 2 elements like [a,b] but I don't know how to do that here. Nor do I understand why? This is a simple multiply operation. The two elements are D101 and AI_CALC_BUFF in this case. Should I also have the raw data from my analog module go into a label as well? The documentation hinted that labels are fussy with 'trigger' events, don't know if that includes my analog module... I'll fidget with that. What do you think?

Figured it out. D100.a is the tenth bit. So... D100.A D100.B D100.C D100.D D100.E D100.F It's in hex for selecting which bit to access, but the device number is decimal. Kinda funny but makes sense.

Hello, quick question, Using the syntax D100.1 as shown above works up to D100.9, but in GXworks3 D100.10 is a syntax error. These are 16 bit devices, how do we access the remaining bits like this?

Hello! I have a tricky issue I cannot resolve. I have an array of 16 independent arithmetic groups where one arithmetic operation group happens and then the next group according to a timer. An arithmetic group is a simple divide and then multiply. I attached an image of the first few groups, there are 16 in total. Background: Arithmetic Operation 1: What happens is when T1 = 1, then D101 gets divided by K32 and stored in D100 (a memory buffer / placeholder) Then D100 gets multiplied by 5 and stored in a unique final destination D121. And then this operation group is done. When T1= 2, the next operation in the ladder happens which is the same code but instead D102 for source value, and D122 for final destination. D100 is always the same buffer memory. There are 16 total operation like this in an array. They calculate accurately so the issue I am about to explain I technically can ignore but... anyways --> The Problem: D122 from the second operation group, for example, will be reset to 0 during that operation group's time. It releases the correct calculated value when the timer moves to the next group. So more specifically, if when T1 = 2 controls D122 who is presently 4000mV, when T1 is = 2, D122 becomes 0mV during this operation time. When T1=3 to move to the next operation group, then the correct 4000mV is displayed (correctly) again.   This is annoying because I have an HMI showing all 16 voltage measurements and there's this sweeping 0 that moves through all the results as the timer counts up, like a refresh 0 showing who's beig updated. It doesnt mess with any accuracy it just makes them all flash zero during their respective calculation time. Hope that makes sense...   It might get annoying later when I start plotting charts in real-time because occasionally this zero lines up with the sample rate of my slower refreshing chart and it will store a random zero in the plot. Might make my field technicians concerned. Initial Thoughts: Since it seemed like it was just held at 0 during the 10ms window (each timer integer is 10ms), then I thought I could try to one-shot it and maybe it will release the resultant number immediately after calculation which is nano seconds. But apparently the P in my arithmetic syntax is already one-shot code: https://forums.mrplc.com/index.php?/topic/4873-one-shot-with-a-math-function/ So I do not know what to do. I just want it to update my value without showing 0. Experiments: The workaround I found was to give more space for my operations like, if my resultant data locations are D121, D122, D123.. etc. The hold-zero issue goes away if I space it out like D121, D123, D125, etc... But I have data constraints that might happen in this large project so I am trying to be space efficient. This arithmetic I am using is supposed to be 16bit only and it's influencing and somehow giving it the next entire 16bit device makes it happier? I don't understand. Again, I get the correct results. I could just ignore this. I might even keep it as a screen saver type function I dunno, I just want to understand the consequences of this phenomenon. Also...: If you know a more efficient way to do my operations I would be much appreciative but don't have to. Thanks!