pop29684

I'm not surprised that your question has evoked no response. A lot of panel builders don't like to use ferrules. I've looked at the three crimper models you listed. If you're using ferrules on wire that's 10AWG or smaller then i'd recommend the Greenlee Wire Ferrule Crimper K30GL. There's no worry about the ferrule being off-center of the die when crimping. The Greenlee crimper automatically adjusts for the ferrule size. They used to be quite a bit less expensive than any of the Euro-designed tools but a quick search shows they currently retail for about the same price.

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!

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.

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.

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.

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!

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).