Host Engineering Forum
Welcome, Guest. Please login or register.
Did you miss your activation email?
November 21, 2017, 05:57:20 pm

Login with username, password and session length

Pages: [1] 2 3 ... 10
 on: November 20, 2017, 11:57:15 am 
Started by Mike Nash - Last post by Controls Guy
Sounds like a case for MAPIO!

 on: November 20, 2017, 10:13:19 am 
Started by Mike Nash - Last post by Mike Nash
Then, of course, remember

Remember... that word looks familiar. I wonder where I, I, what were we talking about?

Thanks. It actually crossed my mind something like that might work, especially at the HMI side. But I am really leaning towards discrete logic after all. Anything using real I/O has a tendency to need addresses swapped around at some point and doing that when I have a FOR-NEXT doing the scaling (never mind PID) suddenly becomes nightmarish.

 on: November 20, 2017, 10:03:20 am 
Started by Mike Nash - Last post by Mike Nash
Thank You.

 on: November 20, 2017, 08:50:48 am 
Started by Mike Nash - Last post by franji1
It did not get into 2.1.  I bumped its priority.

 on: November 19, 2017, 11:39:45 pm 
Started by Mike Nash - Last post by Controls Guy
What I've done for visualizing multiplexed code is have a second code block, in your case a second PID, and the one you want to troubleshoot designate to run in that block.   Then, of course, remember to omit running that loop on the normal PID.

 on: November 19, 2017, 05:27:38 pm 
Started by Mike Nash - Last post by Mike Nash
Thank you franji1.

I was merely looking into options. The FOR-NEXT does give a warning, which is OK, but it also does not provide for the PID View to work. I don't see that it would gain much advantage speed-wise over individual PID instructions. The one PID per scan kludge is a bit quicker at about 0.3mS versus 3.0mS for the FOR-NEXT. This is testing on a real H2-DM1E. The MATH and INTEGRAT to emulate the PV is part of those scan times. Individual PIDs are about the same scan time as the FOR-NEXT from what I can tell. Since I need to have TIMEPROP for all of these outputs, I think the effort has just been a way to pass the time.  Wink

It is a lot more clutter to have individual instructions, but easier to troubleshoot later. My reason for looking at minimizing the scan has been mentioned before, Ethernet comms suffer a large hit with scan time jumping even 3mS. It's not an issue now since we will have 2 processors.

I do like the arrays for the PID along with nicknames. It's way more easy to do the mass changes with the arrays. Data Views are way more powerful/friendly with the array also.

BTW, I was able to get the kludge I posted earlier to work more cleanly by using the PIDs' RanThisScan bit (indexed) to increment the index. It increments more slowly, but more stably. It does want the SampleTime to be the same in all PIDs. Not really ideal perhaps if all the zones are not identical.

 on: November 19, 2017, 04:22:25 pm 
Started by Mike Nash - Last post by franji1
Because PID uses TIME, you DO need to utilize a FOR/NEXT loop to let EVERY PID instruction's PID structure run EVERY scan.

We did 1000 PID loops using a FOR/NEXT loop.  It runs fine.  Since your process is slow, the bump in scan time by a few milliseconds should not cause any issues.

Note that the bump in actual PLC CPU hardware will be greater than the simulator running on a multi-gigahertz class processor on your PC.  30 PID Loops in actual hardware may bump it a few milliseconds on your PLC hardware, which is minimal for most applications (but BRX PLC's high speed I/O can get around this scan time issue).

 on: November 19, 2017, 03:01:40 pm 
Started by PLCGuy - Last post by PLCGuy
wow, that works. I would have never thought of that.
the only thing not working is if someone enters zero and presses PM. I can just not allow zero in the data entry. Or do something when zero is entered.

thank you.

 on: November 19, 2017, 02:41:27 pm 
Started by PLCGuy - Last post by Mike Nash
Try IF(C30,(V1+12)%24,V1)

 on: November 19, 2017, 01:31:43 pm 
Started by PLCGuy - Last post by PLCGuy
Here is the situation. Not everyone knows how to deal with military time.
So I used a math box to convert standard time to military time to deal with the UDT in the plc. All is good up to midnight.

What I have is they can enter in 5 for the hour. That goes to V1. Then I have a button to select AM or PM. C30 on for PM. The results goes to V100. That is now 17. I use that number for my UDT stuff. I wrote if(C30,V1+12,V1). Problem is 12 AM is midnight which is Zero. I can not figure out how deal with 12 plus 12 = 24. I need to change it to Zero for UDT to work.

FYI minutes is coming in on V2. I load them both into UDT1.hour and UDT1.Minutes.

Am I making this too complicated?

Pages: [1] 2 3 ... 10
Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM