Joe E.

OK, what would you use to replace an HMI on DH+? We have a bunch of machines running PLC-5/SLC500 DH+ networks with either PV, PV+, or TCP/Proface HMIs. I would LOVE to replace them as they die with Red Lion or Automation Direct, but neither supports DH+ as far as I have been able to find. We have found only EZ-Touch and Uticor. I've used EZ-Touch before (MUCH prefer Red Lion / AD). A colleague is in the midst of trying to use a Uticor (pending approval of the end user) and it seems OK. Any other suggestions? We don't want to tie up the PLC's serial port with an HMI if we can avoid it.

I'm with you on the Logix 5k stuff. I grew up on Logix 500 which seems much more useful for troubleshooting. It has in-line x-ref if you want it (each XIC/XIO instruction has a hyperlink under it to the coil, the coil has a list of hyperlinks to everywhere it's used as an input). The Custom Data Monitor (CDM) is very similar to the Siemens VAT. You can enter whichever addresses you want to monitor/modify and change their display formats individually. Logix 5 is very similar to Logix 500, but Logix 5000 is a completely different animal. I understand that the L5k processors are significantly different from previous families, but it still seems like the software could have been made more similar and more useful. BTW, I feel the same comparing PanelBuilder 32 to RSView Studio.

We don't have any 5/80s, but here's one from a 5/60. SJ BONDLINE.zip

I'm by no means a motion expert, but I would expect a scaling problem to be more repeatable. I can see a badly measured feed roll causing a consistent error, but not necessarily a random one. It probably seems silly, but are you sure the boards aren't slipping as they're being fed?

You do not need VMWare Workstation to create VMs from scratch. Player will let you create a VM with a blank "hard drive" and install OS on it from scratch, as long as you have the install media. As mentioned, the stand-alone Converter software will make a VM image of a running installation. Just be aware that Windows activation won't necessarily carry over and there may be some hardware drivers that need to be changed/updated (I encountered both problems) but neither is particularly difficult.

What he said ;) If you have a lot of unused COM ports listed under device manager, just delete them and reboot. Windows should automatically find any devices that need them and re-enumerate the ports.

What kind of converter are you using? I'm using a Keyspan model on XP. I have used it under 7 also, but I don't remember having this problem. You should still be able to go to device manager and find the port that the adapter is connected to. Under the settings for that port, you would redirect the adapter to a different port and reboot if it's already "in use". Mine seems to "remember" its setting (COM1 right now) and grab that port first, leaving other devices to get other ports. Once the adapter is installed and running on a particular port, it tends to default to that one until it is changed. Remember, if the port you're changing to is "in use", you'll probably need to reboot before the change sticks. Does device manager tell you which device is using the COM port number you want to use? It seems odd to me that you would have that many COM ports configured. Another option is to delete all of the COM ports and reboot your computer. Windows will find the COM ports that are actually present and reinstall the driver automatically. Incidentally, this is a handy way to get rid of the Allen Bradley PIC module driver.

This appears to have worked. Is there any way to make the PIC driver unavailable to RSLinx? I would like to keep the guys from accidentally setting it up.

We configured the PIC driver on our maintenance computer and it has taken over the COM port. Even after deleting the PIC driver from RSLinx and rebooting, the COM port in Device Manager still shows it. How do we get rid of it? It won't let us use the COM port for anything else. Computer is running XP SP3

It was set up to take exclusive control, but the driver has been deleted from RSLinx. It is not used anywhere else. We just added it to try to connect to a PLC, then deleted it. I tried adding it back in without having it take exclusive control, but it wouldn't initialize (fatal error). When I restarted RSLinx, the driver wasn't there. Right now, RSLinx does not show the driver in its list, but Windows Device Manager shows it having control of the COM port. Nothing is physically plugged into the COM port.

I'm not familiar with Omron stuff, but in general you would put 2 timers on the float switch input in the code. One starts timing when the flow switch closes, the other when it opens. You can use either NC or NO contacts on the switch. I have attached a jpg showing what the code may look like. The timer presets would have to be set appropriately. If the switch flickers, nothing happens, because T4:0 has to finish timing out before starting the pump while T4:1 has to time out to stop the pump. This is a basic switch debounce routine.

Is this something you're doing manually? If you're using Word 2007 and later, it natively supports "Publish to PDF". If earlier, there are a number of PDF print drivers out there. At my previous employer, they had CutePDF. I've also used PDF995. The latter has a "sponsored" version that will show an ad page with each use unless you buy a license.

For my first project at my new employer, I have to translate an old HMI program (uses the old DOS PanelBuilder Development Software) to a PanelView Plus 1250. The display module is 2711P-RDT12C, with a 2711P-RN6 DH+/DH485/RIO comms module. The assembled unit is 2711P-T12C6A2. Our development software is RSView Studio release 4.00.00. I have a fair amount of experience in PanelBuilder 32 but have never used RSView before. It is a stand-alone panel used for monitoring, no machine operations. It will talk to a PLC 5/40B over DH+ (the existing HMI uses RIO). I have it set up on the bench with a PLC and it's talking and everything works except logging in. We would like to block regular operator access to the configuration mode. Using publication VIEWME-UM004C-EN-E, chapter 13, I set up user accounts. When logging in using one of those accounts, the panel returns "Login of user 'USER' failed. Insufficient access rights." In an existing panel, entry of a gibberish user name or password will each return a unique error message, different from this, so I it's not a typo type error. I have a screen that has the <Display Parameters> - <Security Code> set to "A". In the User accounts dialog, the DEFAULT user is set to NOT have access to any levels above *, while 'USER' has access to all levels. When the "GoToScreen" button is pressed for the protected screen, the new panel shows the protected screen, even though no user is logged in. The existing panel displays an error message (as I would expect it to). To make sure I had everything right, I opened the program for an existing PanelView 1500 and downloaded it into the new panel. The same thing occurs, where the protected screen is accessible without logging in, and the login dialog doesn't recognize the user. It all works properly in the PanelView 1500 that is operating in a machine, using the same source code. Is there a setting somewhere I'm missing? Is there a firmware version conflict? I have spent a fair amount of time trying to track this down but haven't had any success. The .apa file for the program in question is zipped and attached. Thanks in advance for any help. BondingLine.zip

Figured it out. When compiling the runtime file, it defaulted to version 4.0. When I select version 3.2, all works as intended.

If you're familiar with VB.NET programming(I'm more of a VB6 guy myself, but I managed to make it work), you can use this control: http://sourceforge.net/projects/advancedhmi/ [i think that's the right package, the video below should clarify] ...in VB Express(free!): http://www.microsoft.com/express/download/ Here's a quick tutorial: He's using a SLC 5/04, but I used the same process with a MicroLogix 1200. This works WITHOUT RSLinx or RSLogix. In fact, if an RSLinx DF1 driver is using the comm port, this won't work. It is quite possible to use the VB program to poll the PLC at specified intervals and write the information to an Access DB. Unfortunately, the test project I created is saved on the computer at the plant, which is now closed.

We ran SP3 on an IBM Thinkpads (Lenovo) with no issues with RSLogix 500. PCMCIA port worked just fine with PCMK card. DF1 comms worked flawlessly with Keyspan US19 adapter. The only trouble we had was with the PIC module (when the PCMK DH485 cable was unavailable) and connecting to older UltraMaster drives using RS232 (random BSOD). I tried to get another laptop to work with the PIC by rolling back SP3. It took most of the shift to get anything working at all and the PIC still didn't work. I re-updated with SP3. I'm not sure if the PIC problem was SP3 or XP itself. It worked fine on our Win98 machine.

Unless, of course, you're worried about that upcoming landing...

We've had good service and performance from Weidmuller terminal blocks.

What Paul (OkiePC) said. How we do it: We keep each machine's program in its own subdirectory within the main "machines" directory. RSLogix defaults to the main "machines" directory, so when we try to go online, we have to select the appropriate subdirectory every time. I would suggest that you look at each .RSS file that goes with that machine offline and determine which has the correct documentation. Move all the other files to another directory. When you go online, it should list the remaining file, which you can select and click "Upload Use File." Once it's online, with the current logic and documentation, go to "File->Save As" and save the current ladder as a new filename. We generally use the name of the machine followed by the rev date as the filename. This helps us keep track of revisions and makes it fairly easy to roll back to a known good program if we make a mistake. There are some machines that we've made a LOT of changes to over the years, some minor, others not so much. We've found this to be a pretty good system for tracking these changes. One advantage we have is that, though we have several people who maintain the code and make changes, we're on different shifts so we all use the same laptop to go online and we don't have to worry too much about multiple versions.

Cool! glad to help

It may seem obvious, but are both transmitters calibrated properly? I also wouldn't think that 10-12 feet of elevation would cause much change in pressure in this case.

If you wish to do the conversion in a cell formula, the Code() function should do it. In a macro, use Asc(). a quick and dirty: in cell A2, enter: =CODE(A1) with "3" in A1, A2 displays "51" In a macro: Range("A3") = Asc(Range("A1")) This is demonstrated, roughly, in the attached Excel file Char_to_ASCII.xls

We haven't heard back from Lenfras yet, so we don't know if he still needs help. Ken Moore's solution is probably the neatest, if it's possible in this case, but this kept nagging at me. I wrote a program (attached) for the SLC 5/04 that converts the floating point value to a string, since there doesn't appear to be an instruction that does it directly. It's actually pretty simple and doesn't involve decoding the floating point format (which is a good thing ). There are some calculations which introduce a slight rounding error, and it sometimes chokes when the input value is near the fringes of valid values for a floating point. It seems to work OK, but, as always, YMMV, test thoroughly before relying on the results, etc. FLOATING_POINT_to_STRING.RSS

I thought of something on the way home. We have the 16 most significant bits of the mantissa stored in N7:17. We can convert that to a decimal value like this: MOV 1 F8:5 XIC N7:17/15 ADD F8:5 0.5 F8:5 XIC N7:17/14 ADD F8:5 0.25 F8:5 XIC N7:17/13 ADD F8:5 0.125 F8:5 XIC N7:17/12 ADD F8:5 0.0625 F8:5 XIC N7:17/11 ADD F8:5 0.03125 F8:5 . . and so on until XIC N7:17/0 ADD F8:5 1.5259E-5 F8:5 Each bit in N7:17 represents a decreasing power of 2: /15 = 2^-1 /14 = 2^-2 /13 = 2^-3 . . . /0 = 2^-16 I'll test this tonight, but we should now have the mantissa in decimal format stored in F8:5=2.004145. We still have to deal with the exponent, however. I didn't think of it before, even though it's what Bob probably meant, but can we convert the floating point number directly to a string? I see, but have never used, the AIC instruction, but it appears only to apply to integers. If there's a way to do that, this exercise just got easier. *******EDITED TO ADD******* OK, I finally got to test this and it does NOT give the correct number. I've managed to extract the floating point to a string, but it's pretty cumbersome. I'll post a new reply with what I came up with.

This may not be quite as straightforward as you had hoped. How much do you know about the floating point format? I've never worked with PLC5 or ControlLogix, only MicroLogix and SLC among Allen Bradley hardware. They use the IEEE 754 single-precision floating point format. The conversion between floating point and decimal formats is not trivial, and is summarized here: 1) Convert the number, including the fractional portion, to binary. In the example given here (0.0000002004145), we get: 0.0000000000000000000000110101110011000110000101 2) "Normalize" this result by shifting the "decimal" point so that it is to the right of the most significant "1": 1.1010 1110 0110 0011 0000 101x2^-23 The red digits become the mantissa portion of the floating point number while the blue number is the exponent. Note that there is an odd number of bits for the mantissa and that the exponent is negative. The most significant "1" is understood to be present, and is therefore not included in the mantissa that is stored. 3) Add 127 to the exponent and convert it to binary. Adding 127 (called "excess 127") saves us from having to designate a sign for the power, allowing all 8 bits to be significant. exponent becomes -23 + 127 = 104 = 0110 1000 4) If the original number is negative, the first bit of the floating point number will be a 1, otherwise it's a 0. The final layout is: S EEEE EEEE MMMM MMMM MMMM MMMM MMMM MMM So, for your number, decimal 0.0000002004145, we get this bit pattern: 0 0110 1000 1010 1110 0110 0011 0000 101 Now, in a SLC, it is possible to work with this, but, as mentioned before, it won't be trivial. I just did a little testing in a SLC 5/04 on the bench. A COP instruction will get the 32 bits into 2 integer elements: COP #F8:0 #N7:1 2 In this example, the most significant 16 bits will be in the first element (N7:1) while the least significant bits will be in N7:2. If you know you will always have positive numbers, you can ignore the most significant bit (N7:1/15). The next 8 bits are the exponent portion while the remaining bits form the normalized mantissa. I found a pretty good converter app here: http://www.h-schmidt.net/FloatApplet/IEEE754.html It is not difficult to extract the exponent portion, using a MVM instruction on the most significant integer element: MVM N7:1 7F80h N7:10 The address N7:10 now contains the exponent, but it needs to be shifted to the right 7 places. This can be done using BSR instructions, or, more simply, using a DIV instruction: DIV N7:10 128 N7:11 To get the actual exponent, we need to subtract 127: SUB N7:11 127 N7:12 At this point, these are the values in memory: F8:0 = 2.004145E-007 N7:1 = 0011 0100 0101 0111b = 13399d (most significant 16 bits) N7:2 = 0011 0001 1000 0101b = 12677d (least significant 16 bits) N7:10 = 0011 0100 0000 0000b = 13312d (result of MVM, the exponent portion) N7:11 = 0000 0000 0110 1000b = 104d (actual binary exponent in excess-127 format) N7:12 = -23d (actual binary exponent after normalizing the original decimal number) We now have the binary exponent. Unfortunately, the mantissa uses 23 bits, which is too much information for a single 16-bit integer element. Depending on how we handled the data, we could use AT MOST only the most significant 16 bits of the mantissa, but we would lose precision without it necessarily being apparent. If we change the least significant 7 bits of the mantissa to 0, the original number becomes 2.0041443E-7. If this is accurate enough, we can proceed, using only one integer element for the mantissa: We need bits 6 thru 0 of N7:1 and bits 15 thru 7 of N7:2 combined into a single element. Here goes: MVM N7:1 007Fh N7:13 We'll want to shift this to the left 9 places so they are the most significant bits of our final element. If we just multiply by 2^9, we will cause overflow, so multiply by 2^8 and use a BSL: MUL N7:13 256 N7:14 OTU R6:0/EN BSL #N7:14 R6:0 B3:0/0 1 Now, we need to extract the next 9 bits of the original mantissa, which are bits 15 thru 7 of N7:2: MVM N7:2 FE80h N7:15 This needs to be shifted to the right 7 places, so divide by 2^7: DIV N7:15 128 N7:16 Gather the appropriate portions of N7;14 and N7:16 into our final mantissa: MVM N7:14 FF80h N7:17 MVM N7:16 007Fh N7:17 N7:17 now contains the most significant 16 bits from the mantissa of the original floating point number. Keep in mind, that this integer CANNOT be used "raw!" It must be interpreted using the IEEE standard and the exponent above. Remember that there is another "1" in front of these 16 bits AND that, if the first bit is a 1, the integer file will show a negative number that is NOT the same magnitude as its positive counterpart. SLCs store integers in 2's complement format, which uses the most significant bit as a sign bit. 2's complement is a bit involved to discuss here, but it's explained in Appendix F of Publication 1747-RM001E-EN-P. As a quick experiment, store "400" in an integer element using the datafile or a CDM. Change the radix to binary and set the sign bit. Change back to decimal, and it is -32368. To make the final data simpler to handle, we can drop 2 bits, using only the 14 most significant bits of the mantissa. We will lose more precision, with our original number now 2.0040898E-7 If this is OK, modify the above code thus: MVM N7:1 007Fh N7:13 MUL N7:13 128 N7:14 MVM N7:2 FE00h N7:15 DIV N7:15 512 N7:16 MVM N7:14 FF80h N7:17 MVM N7:16 007Fh N7:17 OTE N7:17/14 The last line of code sets bit 14. Recall that there is a one preceeding the "decimal" point that's implied in the IEEE format. The bit pattern in N7:17 is now the most significant 14 bits of the mantissa with the bit before the "decimal" point set. The sign bit is still not evaluated here. I'm not sure how useful all of this is, though (not at all, yet). Now, we have a 15-bit mantissa that we may or may not be able to do anything with. Because of the complexity of the IEEE conversion, going back and forth between binary and decimal, I don't know that we can accomplish what you're asking easily. The exponent portion of the floating point number is the binary exponent, not the "-007" in our example, and there doesn't seem to be a simple way to extract it. If you know where the decimal point will always be, in other words, if the number will always be x.xxE-7, you can simply: MUL F8:0 10000000 F8:2 ...and then do the string parsing from there. BTW, the code here is a bit longer and uses more memory locations than really necessary, but I think it's clearer. Bottom line: it may be "easier" to display the information on an HMI, maybe have the HMI do the printing. Is that an option? Sorry for the disjointed post. I've run out of time for now, so I'll have to revisit this later. Or, someone else with better ideas may post. I've never really tried this, so it's been a learning experience for me, too!