Andy_P

I have a small project where a CP1L-L-14 is communicating with a NT21 screen via NT-Link 1:N method. A problem exists when I try to display anything from the data memory area from D32000 up to the end. Specifically, I need to display something from address D32700. According to the CP1L specs, the area from D32000 to D32767 is free to use. (I am aware that D10000 to D31999 is not available on this model.) For example, a simple 'Numeral display' of D32700 results in an 'Addressing error' displayed on the NT. Addresses at lower range of D0 to D9999 work without problem. Loading the same program into a CP1L-M PLC works ok with the same screen. Also, CX-Programmer can interrogate/modify these addresses with no problem. All my tests indicate this is a problem with this specific model of PLC, and possibly with the NT Link communications hardware/firmware/something else within the PLC. At this time, my local Omron tech support cannot give me any answer, other than to try and use the latest version of NT Support tool (V4.82). As I expected, this had no effect. Has anybody else encountered this, or can confirm this is a bug in the PLC? Using: CP1L-L-14 V1.0 NT21-ST121-E V1.03 Thanks.

@bluebyu Thanks for trying this with your kit and confirming it works. I am hoping someone can try with the specific kit I have: CP1L-L-14 & NT21. Thanks.

Anybody else replicate this issue?

No prob. I have had this issue being looked at by Omron tech support here in UK about a week now, with no reply as yet, other than 'It is being looked at in Japan'. I like to give the tech support guys proper problems to deal with.

Thanks for the replies. @Jay: I am not using memory in the region allocated for Modbus, nor am I using Modbus. @PMCR: I can currently use the area successfully with CP1L-M and CJ1M PLC's. You mention loading new 'firmware'. Do you mean the firmware in the PLC or the screen? (Is it possible for an end user to update the firmware in the PLC?) The only reason I am using this area is to store/display some rarely changing parameters in my programs, and it has not been a problem until now. It just seemed a good idea to put them up there out of the way. It would be a trivial thing to reprogram and use another address of course, but I am just a bit curious/concerned if there are any other underlying issues waiting to bite me later on. At the moment, it is a minor annoyance as it would mean moving a few things to different addresses which would make it a bit non-standard to a the rest of our equipment. If any of you guys feel like trying to replicate this issue with your own hardware, I would be curious to see if you have the same result. Thanks!

When programming using SFC, it is possible to associate an 'Indicator variable' to each action of a step. I'm not really seeing the point of these, as they don't appear to do anything useful. I'm just wondering if I am actually missing the point or using them correctly. So, anyone use them? If so, how, and under what circumstances! Thanks. Andy.

Thanks anonymous. I suppose then that it makes more sense to use one when an Action is more complex than simply turning an output on or off. (Which is pretty much what I have been doing as I don't have a proper project or application that is suited to SFC.) A simple 'coil only' action is pretty much described by the step name or action name in itself. Andy.

Look up the interlock instructions IL and ILC, I think they may be what you need in place of MC and MCR. The attachment is from a CP1L/CP1H manual, but it should be the same for a CS1D. Hope that helps. Andy.

Congrats! So, will it be VB, Crownies, Carlton, Tooheys or all of the above?!

A contactor implies a relatively large electro-mechanical device to me. If so, I am sure the energising response time could easily be as long and potentially even longer than the cycle time of the sine-wave (assuming a 50/60Hz wave which gives a cycle time of 15-20ms). The coil could be energised by an output and it would give largely random timings for which part of the sine-wave it operated I am sure. Hope I have understood your problem correctly, as I made a couple of assumptions. Andy.

On the Omron press release about the CJ2, it says: "Errors reduced when modifying designs because tags are used for actual I/O and internal I/O, eliminating the need for address allocation..." Is this something new? Or is it referring to the way you can change an address of a symbol in the symbol table, and it automatically changes all the occurrences of that address in the program? (I love that, by the way!) Andy.

Thanks! Unfortunately the link it points to isn't that great. Andy.

I think that is correct, yes. I am using CX-One V3, which includes CX-Programmer V7.2, CX-Server V3.1 and no support for the CJ2. Got to say, I find it very strange that there should be this disparity between versions around the world, very confusing. Come on Omron, sort it out! Andy.

PLC Law #49: The answer to ANY "Can you make it do that?" question is ALWAYS yes. No matter how much you would love it to be no. PLC Law #49.1: When your boss asks this question, it really means: "You are going to make it do that. At no extra cost. And in the next half an hour." Andy.

Hehe, you have somewhat resurrected this thread from the dead! However, I agree with your sentiments on the Express editions. I have used both VB.NET and C# Express. Very impressive considering they are a free download. I have used VB to build a datalogger app that talks to an Omron CJ1M via serial link. Currently trying to learn C# and port it over, and trying to implement some TCP sockets functions. Andy.

Amen to that. It enables me to have a lot of standardised code for a range of machines. Not just FB's, but just regular ladder, because the instruction set is the same, and on top of that, the memory addressing is the same also. The only thing I have to worry about is the actual I/O addresses. Andy.

A ha, yes! But does that require a manual button press to use it? Andy.

Does the NS5 have the macro facility like an NS8 for example? If so, check this out from the macro reference manual: Andy.

I guess it is somewhat confusing to somebody fresh to the world of PLC's as the principles involved are a bit different from programming PC's with VB, C++, C# etc. On a slightly different subject, although still relevant to the idea of a PLC scan: Suppose you have a physical output that controls a lamp, relay etc. If you turn this output bit on and off a thousand times from with your program, this does not mean you will see your lamp turn on and off a thousand times. The lamp will be set to the state that the bit is in at the end of the PLC cycle. A similar process occurs for inputs. If you have a switch connected to an input, then the bit it addresses is scanned at the start of the PLC cycle, and the status of this bit is used throughout the cycle. If you somehow managed to flick the switch a thousand times during the cycle, the status of the bit in your program will not change. (At least not with regular inputs and regular programming, but let's not get into that right now!) This is worth knowing, because it means that if an input signal duration is quicker, or indeed the same length as the PLC cycle time, it is very likely that the signal will be missed. I believe that a good rule of thumb is that the signal duration of a regular input should be at least twice the length of the PLC cycle time, to ensure that it is not missed. This includes both the on time and off time of the signal. Hope that helps! Andy.

Yes, the bit comes on immediately, wherever he DIFU instruction is. It stays on until the end of that cycle, and right the way around the following cycle until the DIFU instruction is encountered again, at which point the bit turns off if the logic preceeding the DIFU is still true. Andy.

Yes, yes, but that is far too easy. It's Saturday afternoon, and I'm off duty. What can I say?

The 'First Cycle Flag' for a C200H is address 253.15. I don't think there is a specific flag that is off for just the first cycle. Maybe you could set a bit at the very end of your program?

Will there be beer? Will there be anyone else other than a ship-full of PLC geeks? And can mere peasants with less than 150 posts come too?

To be honest, I think this explanation from Scott is a pretty good one: To try and put my own spin on it: A bit that is DIFU'ed will be set to true once the preceeding logic is true, and it will stay in this state for 1 PLC cycle. If, on the next cycle, the preceeding logic is still true, the DIFU'ed bit will be set to false. I think the key to all this is understanding the concept of a PLC cycle. At the risk of confusing things further... Where you have written the code snippets like this: *** TASK B *** RUNG 1: IF BB then DIFU AA RUNG 2: Do Stuff *** TASK B *** Are you expecting that the 'Do Stuff'' code in rung 2 will be executed only when there is a DIFU of bit AA? This will not happen unless there is a condition of 'AA' in there. Otherwise, it will always execute. I hope I haven't muddied the waters still further. Andy.

If a task only executes for one scan then I am pretty sure this will mess up any DIFU or other edge trigger instructions that occur within it for that matter, as it needs to see the next cycle to turn the bit off. If tasks that have the same bit DIFU'ed run consecutively, then I am pretty sure that this will mess up the state of your bit too. In my opinion, it would be better to have all your DIFU instructions act upon individual bits, otherwise you have an output duplication problem. A DIFU instruction sets the bit on which it is applied to true for one cycle of the PLC scan, when the input logic to it is true. To re-DIFU the bit, the input logic must become false first, and then back to true again. I know what you mean about being a PC versus a PLC programmer. It is a totally different kettle of fish!