Andy_P

IMHO, isn't that the whole point? Other than that, if a block of code that is doing a complicated job can be represented by a 'black box' with inputs and outputs connected to it, it is much more accessible to non programmers (eg. maintanence personnel) who perhaps have to monitor and interrogate a PLC. Assuming the internal code of the function block has been carefully debugged, the process of how the inputs control the outputs can be largely ignored by someone such as this. They will only need to know what to expect given a set of circumstances. Having worked on both sides of the fence, (maintenance and programming) it is easy to lose sight of the fact that other people may have to look through your code, and as such the KISS method is always a good thing. Andy.

The first thing to check is if the rated load of the output relay is sufficient for the devices you are controlling. If you are driving a DC device then the usual basic way to supress arcing across contacts is to wire a diode in reverse across the connections of the device. This is standard practice for any kind of DC load like relay and solenoid coils. Another option is to have the PLC output drive another small relay which in turn switches power to your actual device. Even if your small relay then fails, you only have to replace this and not your output card. Obviously, when choosing relays for this job, loading considerations have to be taken into account. Hope this helps. Andy.

So, has anybody had a go with any function blocks yet? If so, what is their opinion? Unfortunately, I am told CXP V5 is not being released in the UK until well into next month, and V3 PLC's sometime after that. Andy.

I think you find upper and lower byte enable signals (defined with various labels) on RAM chips and the like, that enable microprocessor access to either one half or the other, or indeed the whole 16 bits of a databus. If that is what is being queried, then I guess it is beyond the scope of this forum, as it deals with internal workings of an Omron module? Andy.

I have come across a couple of small problems with the V5 system program for the NS8. I understand that the latest system program is now V6, but I haven't seen any screens with that that yet, so I don't know if the following problems have been sorted out. 1. When the 'flicker' control is applied to a bit lamp, and the flicker mode is set to use 'on and off colours alternately', the following problem becomes apparent: Any label text for the lamp is displayed as 'Standard 1x1' font while the flicker is in progress, regardless of what font it is set to when the lamp is not flickering. When 'flicker' is off, the text changes back to the original font. 2. If a separate label object is overlaid onto a blank lamp (ie it has no text), and the lamp flicker control is turned on, the label object disappears. When the flicker bit is turned off, the label reappears. These errors do not occur if the NS-Designer test mode is used, so I figured there is a couple of bugs in the screen system prog. Has anybody else come across these problems? For my part, they are not a big deal as I normally control lamp flashing from the PLC, but I thought I would ask the question. Andy.

No problem, although I don't think 'genius' is quite right. I'm basically very lazy, and I always try to find a shortcut to everything! Andy.

If I understand you correctly, you are using multiple labels, defined by the 'Switch Label' tab in the 'Settings->Project Properties' dialogue. You then have numerous text objects which have differing texts depending on which 'Label' you have selected. If these two assumptions are correct, then the line from my previous post is correct: Next, to move to the next 'Label' setting, you can scroll through all of them by clicking on the 'Next Label' or 'Previous Label' buttons that are on the 'Functional Object Operation' toolbar. (They are indicated by the word CAP with an arrow beneath them). You may have this toolbar as a floating window. You can do this with all of your objects selected and change colours, fonts etc, for all of your label settings. Hopefully I have understodd you correctly and have not cofused the issue further. Andy.

Can you just select many of them at a time by holding down the Shift button, then change colours etc from the Formatting toolbar? This will then change all that you have selected. Andy.

Hmm, don't know why. I have the option for 'CSV(Comma delimited) (*.csv)' in my save as list. Don't know what, if any, the differences are. Have you tried exporting a screen, and then importing it back again without making any changes to the file? Presumably this should work ok. Or how about exporting a screen and making an edit in Notepad, although this is very painful. Another idea - export a screen and check if it will import without any changes being made, as suggested above. Make a copy of the file and load it into Excel and then save it. You can now compare both these files in Notepad to see what, if any differences have occurred. Might give you a clue to what is going on? Good luck! Andy.

I am using NS-Designer V5. I am also using XP with Excel 2000, and this method works for me. 1. When exporting a screen to a CSV file, I always export it with the 'output code' selection set to 'ASCII'. 2. This allows Excel to open the file without it prompting you for any kind of formatting instructions, such as 'type of delimiter' etc. 3. Make any changes as required. 4. When 'save' is selected in Excel, it brings up the 'Save As' dialogue., annoyingly. 5. Highlight your file, to overwrite it, and ensure that the 'file type' is set to 'CSV(Comma delimited) (*.csv)', and save the file. 6. Excel further annoyingly tells you that the file 'may contain features not compatible with CSV', and do you want to 'keep this format'. Select yes. 7. Even further annoyingly, when you exit Excel, it asks the question 'do you want to save changes', even though you have just done so. Answer no, or you will enter into a never ending loop...... 8. Now your file can be imported back into NS-Designer with your changes included. Hope this helps! Andy.

I have downloaded a file from the Allen-Bradley forum that demonstrates how to use DDE from a PLC into Excel to perform a data logging application. It appears that the DDE communications are performed with a program called RSLINX. Is the the Allen-Bradley equivalent of Omron's CX-Server? How can this data logging application be created using Omron software? Would it be throught the use of the DDE Manager that is supplied with CX-Server? Can DDE Initiate and Execute from Excel to this package be performed? Thanks in advance, Andy.

Is it possible to determine if an instance of Excel is running with any CX-Superviser script code? I can auto-run Excel ok with the following command: where the point 'FullPath' contains the neccessary path information to Excel, and the point 'ExcelOpened' is set to 1 when it is executed. However, if the user exits Excel themselves, the point 'ExcelOpened' stays at a value of 1. Is there any command or code (possibly @VBSCRIPT?) that will allow me to find out if it is running or not? I am running CX-Supervisor V1.0 Thanks for any help or pointers. Andy.

There is the 'Workbook_BeforeClose' event, which I had thought of using. Tried a DDEPoke routine (see below) along the lines of the example given in the CX-Supervisor user manual, but I can't get it to work. This routine placed into 'Workbook_Open' event: 'ExcelRunning' is an Integer memory point with DDE read/write access enabled in my CX-Supervisor points database. Running the above code in Excel does not appear to create a link, as the 'DDEChannel' value remains at 0. I cannot find out why this does not work. Can't find an application OnClose event, or similar. Guess it might be a bit more involved with Windows and API. Ouch. Anyway, for now I can put some code in the 'Workbook_BeforeClose' event that cancels the event. This has the effect of not allowing my workbook to be closed and also stops Excel closing also. It's not ideal, but I will have to live with it for now, until I can find a better way of doing it. Back to the drawing board.... Andy. (PS. Should I have posted this onto an Excel message board?! )

Personally, I can't wait to get my hands on CXP V5.0 and have a go at some function blocks. I downloaded an introduction to them from the Omron website, and they appear to be very similar in operation to function blocks used with Siemens. At least from what I used to use with Siemens Step5 anyway. If that is the case, then they will save me an awful lot of work and PLC space, as I can repeatedly call a common function block with different parameters to run very similar pieces of kit. Have toyed with the idea of using the MCRO function, but I don't personally like it as its not too user friendly, and I find it fairly difficult to see what is going on when monitoring a program. Oh well, that is just a couple of opinions on the subject from me. Feel free to agree/disagree etc! Andy.

OK guys, fair point about browsing the download forums. However, perhaps I didn't phrase my questions very well. Some of the code in the Allen-Bradley Excel download contains lines such as: This implies to me that Excel can control when a DDE link is established, and furthermore which bits/words to read from the PLC. With Omron's DDE manager, you have to set up which PLC points are to be permanently linked to specific cells, and are automatically refreshed depending on the update interval, or updated manually with some sort of 'Update Links' command from Excel. This means that the DDE manager is the controlling influence and Excel cannot read from PLC areas that are not already linked with the manager project. Am I right in this? Could I hack around the code quoted above, substituting RSLINX with CX-Server, and changing the AB PLC points to Omron ones? Hopefully this is not going over too much old ground, apologies if it is. Thanks for your patience, Andy.

I never knew you could do that. To accomplish this I had been using a push button in 'Set' mode, and a macro to reset the other bits relating to the other radio buttons. The 'Group' method is much more elegant and simple to put into operation. Will definitely be using that method from now on. Thanks Jay! Andy.

Hi, Thanks for your help. Based on what has been said, I abandoned my attempt with Xp and found a PC running Win 98 with a real serial port. The PL7-07 software correctly installed and I was able to connect to the PLC straightaway. My suspicions were confirmed when the PLC appeared to contain no program. I obtained a replacement PLC (not going to trust the old one), and managed to get hold of a copy of the required program. The 10-position switch near the comms port is set to 0. I presume this is some sort of unit address setting? I was able to load the program using the 'Transfer, PC->PLC' menu option, and got a flashing green run light. Clicking on the 'Run' command turned this into a solid light, and everything appears to be ok. One question remains however. Under the 'Transfer' menu, options exist for transferring to/from an EEPROM. Does this mean an external EEPROM, or an EEPROM inside the PLC? Will the PLC hold its program from what I have explained above, or do I need to do a 'Transfer, PC->EEPROM' too? Many thanks for your help, much appreciated. Andy.

Currently I have an extremely basic grasp of protocol macros and their use. I have just about got to grips with using some from the 'ASCII Generic' file located on this site. Digging a little deeper, I would like to understand the entries 'Address' and 'Length' when it comes to constructing a send or receive message. Reading the manual, it appears that 'Address' is only required when using a multi-drop connection and the unit number of the connected device is required. Is this a correct assumption? If so, does this mean that for single drop, RS232 connections, the 'Address' entry is never required? The 'Length' entry appears to truncate a received message to this length (bytes or words?) if it is greater than this value. Once again, is this a correct assumption? As for transmitted messages, I'm not too sure how this works! Any help with these queries would be grealty appreciated. Just by scratching the surface, It appears to me that protocol macros are extremely powerful, so I would like to learn more about them. Andy.

Currently using PMCR to transmit a very basic string with no reply to a PC, reading data from a Microscan barcode reader (MS-3 and MS-911), and also receiving a very basic string from a machine built by my company. I am only using PMCR because it was forced upon me, although it may prove to be a blessing in disguise. Now that I understand the terminology and construction of protocols a bit more, I have been able to look at the system protocols with a bit more understanding. My current level of knowledge is adequate for my present applications, but I always like to try and stay a step ahead for any future problems that may arise. At least I know enough now to have a play around and have a fighting chance of working out what is going on. Thanks, in no small part to the help received from this board. Nothing worse than trying to learn something new and complicated when you have deadlines to meet. Andy.

Thanks Jay, this makes much more sense now. All I have to do now is learn the remaining 99% of protocol macros and I might be getting somewhere.... Andy.

Thankyou for your replies. They have answered many of my questions. The 'Address' entry now makes sense. Case closed! The 'Length' entry.... Could you please clarify my assumptions, below. For transmitted messages: A value is calculated by the protocol and inserted into the string at the required position, in either binary or ASCII format. For received messages: A value is already present in the string indicating the length. It is not calculated by the protocol. If a string has, for example 20 characters, but the length character indicated 10, then the entire message would be received, but only 10 characters would be transferred to the PLC. Thanks for your patience! Andy.

I find if you keep it simple and make it look flash, the managers will love you too! Andy.

I know what you mean. Amazing what a weekend off can do isn't it? Presumably you are using the function SHOWPAGE(n); in your macro. One point to note, if you haven't found out already, is that anything written after this line in a macro will not be executed. Wrong: SHOWPAGE(n); $SB12 = 1; <--- This line is not executed Right: $SB12 = 1; <--- This line is executed SHOWPAGE(n); Andy.

This is just of the top of my head, I haven't tried it but can you just put the line: $SB12 = 1; in the 'When Loading a Screen' macro of the screen in question? This macro is accessed by looking at the screens properties. Also, you could put the line: $SB12 = 0; in the 'When Unloading a Screen' macro of the same screen to turn the buzzer off, if that is what you desired. Indeed, these bits can be manipulated from within any macro. (I believe.) Further, you can control the '$SB' bits from the PLC. You should have an area set up by looking at the 'Initial' tab of the Settings>Sytem Setting menu. If the 'System Memory', '$SB Allocation Address' is set to HR100 (for example), $SB12 represents the twelfth bit of this allocation, in this case HR100.12. Toggling this bit from the PLC will toggle the screen buzzer. Hope this helps. Apologies if I have some of my facts wrong, but it's been a long day! Andy.

Definitely agree with using a USB memory stick. Or even using a flash card reader. I have lost count of the times I have found the latest floppy is dead, or reads on one PC but not another, and then having to waste time finding another one. Andy.