MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

14 Good


About pop29684

  • Rank
  • Birthday 12/19/56

Profile Information

  • Gender Male
  • Country United States
  1. I've been handed a project that includes writing code to control the fan and pump speeds in a process water cooling tower. I will know 1) the outside air temperature (reference), 2) the temperature of the incoming return process water at the tower, and 3) the temperature of the outgoing process water supply at the tower. The customer has specified a linear relationship between TWST and velocity of the tower fan and pump speeds. They also want both the tower fan and tower pump speeds to match each other. I have two questions: 1) what other data might be necessary to consider, and 2) what would the algorithm look like? The VFDs will be driven by a 0 - 10V analog signal. This seems to me that a percent of speed would be easier to implement. I'm guessing that the setpoint of TWST needs to be subtracted from the reference OAT (if OAT is higher than TWST-setpoint), and this difference should be manipulated into a percent of the 10V analog signal to drive the VFD. Is there an easier direction that can be recommended? Thanks!
  2. ProfiSafe Using TwinSAFE

    Has anyone implemented ProfiSafe over TwinSAFE? Would you recommend it? What obstacles or quirks did you need to resolve? Would you do it again?
  3. Hardwired PLC to Wireless via bridge?

    What is the purpose of having a PLC CPU on a mobile rack? Will the envisioned mobile PLC also have I/O attached to it via a hardware rack on the mobile cart? Will the envisioned mobile PLC be connected to any remote I/O via the bridged network (I/O mounted in a stationary remote location? Is the plant network secure - is it isolated from any connection to the outside internet? What is the intended wireless connection to this envisioned mobile PLC - a machine, a PC, etc.?
  4. Best brick PLC for learning

    You can get a Codesys license for Raspberry Pi. Last I checked it ran around $125 USD.
  5. Need help with Timer Logic

    You may be correct. I was thinking of the Siemens platform where the TON instance DB is accessible.
  6. Need help with Timer Logic

    Do not modify the existing time logic of TON_1 and TON_2. Instead, when BOOL_tag state goes to "1" then move the final value of TON_1 into the active timing register of TON_1. This would be "0" if TON_1 counts from preset value to zero; this might be "100" if TON_1 counts from zero to preset value. You need to verify the operation and final value of TON_1 in order to realize what is the final value of TON_1.
  7. Upload S7-1200 Siemen PLC with TIA Portal v14

    Try performing a "compile hardware & software". If differences still exist you will need to perform a full compare (not the quick compare). De-select all filters then begin re-selecting the filters one by one until the difference returns.
  8. PLC Programming Language

    Where do you plan to do most of your work? As a general rule of thumb, ladder logic is the most common here in the United States. But if you're interested in working in the European market then perhaps function block diagram or structured text would be the better choice.
  9. Perhaps a good application for a simple heartbeat bit? If the bit isn't seen, track the length of time it is missing. Probably not accurate down to the second but might be worthwhile.
  10. Heidenhain EnDat

    I'm afraid I don't have any answers for those questions. I have never used the encoders you are referencing. I hope someone else on this site would kindly supply an answer.
  11. Heidenhain EnDat

    Have you contacted Heidenhain? Here's a link from StartPage to a PDF: https://www.heidenhain.be/fileadmin/pdb/media/img/587718_08_A_02_Drehgeber_fuer_Aufzugsindustrie_en_01.pdf. I think you might find your answer (or at least get a direction) from page four. Perhaps the ECN 113? Note the shaft differences between it and the model you currently have!

    The efficiency is immediately obvious. The need for VB50 - VB54 is eliminated. The need for the repetitive call of the SEG instruction is eliminated. True, the SEG instruction will conveniently convert a digit on the fly to a segment map but at the expense of, arguably insignificant, longer scan times and more memory usage. Manually mapping the segment values will reap the benefit of using less code, having less module calls - all of which translates to saving a little scan time and memory. But perhaps this is not important in the project with which you are working. Or perhaps you are determined to understand the operation of the STL/SCL code. Or maybe you want to build your own SEG module that, when called, takes the single digit integer and gives the appropriate 7-segment map value. As far as the DWord contents, if you know the 7-segment map value that you expect in the byte, then it is a simple matter to compare that value to the values in the four bytes of the DWord. Then you know exactly which byte contains the data you need. Good luck, my friend!

    Why would there be any data in the other three bytes? The logic only requires one byte to hold the necessary segment map, correct? Is your calculated result being expressed as a signed integer in a DWord?

    Is your output variable addressed as a double word (DWord)? If so, perhaps it should be addressed as a word or even a byte. If not, you may need to convert from a DWord data type to a Byte data type. That discussion is on p109 of the Siemens S7-1200 Easy Book (found here: https://euroec.by/assets/files/siemens/s71200_easy_book_en-US_en-US.pdf).
  15. Thought I'd share an experience I had earlier today working on a (limited memory) L61 Rockwell processor. I knew there was very little room left in the memory but needed to add some functionality and decided to give it a try anyway. I couldn't take the machine down to make a download so made a number of online edits, successfully accepting and finalizing after each edit. Got down to the last four edits which required zeroing a tag of type REAL. The instructions were on four separate rungs. Hoping to save time (and all previous edits were successful), I added the four MOV instructions (MOV 0 into TAG) and pressed the "finalize" button. I was caught quite off-guard when the process failed: insufficient memory. AAAAGGGGHHHH!!!! So close! I tried to remove some logic to free enough memory to add the required instructions. Nope. Rockwell was not going to negotiate. That left me in a position where I thought I was going to have to take the machine down and do, hopefully, a download that would push the processor memory to the limit but be accepted without any hiccups. But before I did that I had a fortuitous thought. I F1'd the MOV instruction and hoped to find a complete explanation of the instruction, including timing diagrams, execution time, memory requirements, etc. Oh wait - that's Siemens. GROAN. Curious and desperate, I replaced each MOV instruction in my edited code (I'd estimate somewhere around 20 instances or slightly more) with the CLR instruction - including the four additional instances I needed. And finalized the edits with bated breath. To my utter surprise (again!) the edits were finalized without overrunning the memory. A MOV instruction requires memory for both the source and destination. Since I was only clearing a memory I didn't need to reserve memory for the source. Using a CLR instruction implies "0" (zero) for the source but requires no memory for the source value. Hence the efficiency. Obviously, this story would have a different ending if I had been trying to move some value other than zero into a destination tag. I offer my experience as a lesson if you ever need to streamline some code to fit existing memory space. I also would like to know if there are any downsides to what I've done. Have i overlooked any potential pitfalls? Thanks in advance for the advice.