-
Content count
123 -
Joined
-
Last visited
-
Guest liked a post in a topic: Need help with Timer Logic
-
pop29684 started following 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?
-
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.?
-
You can get a Codesys license for Raspberry Pi. Last I checked it ran around $125 USD.
-
You may be correct. I was thinking of the Siemens platform where the TON instance DB is accessible.
-
pop29684 started following 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.
-
pop29684 started following 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.
-
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.
-
Knowing length of time PLC was powered down
pop29684 replied to Mspeck's topic in Allen Bradley / Rockwell Automation
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. -
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.
-
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!
-
pop29684 started following Heidenhain EnDat
-
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).
-
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.
-
pop29684 started following Replacing MOV with CLR
-
Thanks, Bob.