Andy_P

Recently upgraded to V1.08 (Module V1.0.8.29). Happy to see the variable lists can now be sorted, although I cannot add any variables when it has been sorted. You have to close the window and reopen it which took me a while to figure out. Also, previous versions ran quite slowly, but this one is REALLY SLOW. Scrolling through a large POU takes an age for it to catch up, especially when you are online.

I'm looking for a user / programming manual for the FJ-355 vision controller but not having much success. Can anyone point me to a link or upload one? Thanks.

Something I am finding annoying is the inability to sort the Global Variable table (or the Internal/External variable tables in a POU for that matter) by clicking on the column headings. Hopefully that will come in a later version. I am using V1.05.31.

Hi, I'm trying to trigger a FZM1 vision controller over Ethercat. Setting the EXE bit results in the FLG bit coming on to indicate process complete, but I always get a response code of 0xFFFFFFFF, which indicates command execution error. I get this for any command I send, and the controller does not trigger. The manuals offer no clue that I can find for why the command would fail, simply that 0xFFFFFFFF is a fail. Manually triggering the controller from the interface works OK. Anyone offer any help???

I'm finding the Sysmac Studio software to be a little slow, especially after a long period of use as it seems to get bogged down. I guess further upgrades will start to address this and other issues though. Using tags has taken a little getting used to, but on the whole I'm getting on OK with it. Certainly is a different way of thinking with regard to PLC programming. I didn't know you could set all the Ethercat node address switches to 0 and have them assigned via software. Nice!

The built in "Decoder" instruction on the NJ controller has the ability to decode up to 256 bits. I'm trying to make a decoder function block that handles up to 512 bits, but brain-freeze and Friday afternoon means I'm struggling a little. Can anyone point me in the right direction? Thanks for any help.

( CX-Designer version V3.520 October 29th 2012) Following on from my previous post regarding grid size, it appears there is also a bug with the data format of the screen page value. Despite setting it to Binary, it is still operating in BCD mode, at least in simulation. These are pretty fundamental errors and I really hope that it is only me that is experiencing them. Anyone else?

Aha! That is indeed precisely where I was going wrong. Working now as expected. Thanks for pointing me in the right direction.

Hi Michael, thanks for your reply. I have found the solution to the problem, but it is one I am a little surprised by: On my laptop, the default setting for text display size is set to 125%. Setting this to 100% subsequently allows the grid to be displayed correctly, and objects that are created to fit the grid as you would expect. I would assume that is counts as a bug in CX-Designer, as it becomes not truly WYSIWYG. Maybe you could try altering the text size on your PC/Laptop and see if you get the same issues?

I am using CX-Designer version V3.520 October 29th 2012 and have an annoying problem. For example, if I set a screen grid size of 8x8, then the actual grid displayed and snapped to is 10x10. If I set 20x20, then I get 25x25, etc, etc, and other variations. I'm currently designing a project for an NS15, but the same behaviour is exhibited for other screen project sizes too. Anyone else experiencing this? Known bug?

Hi, I have been dumped with a few problems to solve with a TSX-Nano PLC from Modicon/Telemecanique/Schneider (who the hell makes it?!). I have zero experience with this PLC so please be patient... The PLC in question has no status lights on except the ERR light which is flashing. From what I can make out, this means that the 'Application cannot be executed', which I guess means the program is corrupted, or even wiped. Possibly backup battery faulty? Am I correct with this assumption? I have acquired (legally!) some software by the name of PL7-07, which is a DOS based program. After installing it, I just cannot get a connection to said PLC. Digging a little, it appears that files by the name of 'DUNTL' are missing. Why didn't they get installed? I have tried numerous installs, but no luck. I have also tried all conceivable permutations of the 'Programming port' setup but no joy. How do I know what parameters to set the comms to? Is there a way of setting default settings as there is with Omron PLC's? I do not have a copy of the program on file, because apparently 'There has never been a problem with this machine so we didn't need one'. So even if I do get connected, I might still be screwed.... I have installed software onto a PC running XP Pro, with connection through a USB to serial converter. (I have a horrible feeling about this...) Could there be a fault with the PLC that will not let me connect to it? I appreciate there is a lot of questions there, but if anybody could shed any light onto any of them, I would be very thankful. several times. Andy.

Good luck to PMCR. Do you get a pay rise?

My cheque is in the post Jay.

Hi Pp, I had heard about these new models, but did not know they were released yet, much less know what part number they are, so thanks for that. @BobB & JayAnthony: In my defence from the old pfhaarts, I don't use FB's too much. Fortunately, the customers we sell to have no capability or even intention to interrogate the PLC. The code is occasionally inspected by my in house colleagues though. If I had a situation where code change support was required for a customer 2 days plane journey away, then I absolutely agree. Ladder is the only way.

Yes, the CP1L is a great little PLC, in my opinion. As for FB's, I hear what you are saying, but I do like them when it comes to doing lots or repetitive things, and you can just drop a "black box" into the code. Also I like to use the odd ST function block too, when the equivalent ladder logic would be a bit unintuitive to look at. (I have to consider other people looking at the program, and not just myself.)

The CP1E has no function block capability? Seriously??? If that is true my local Omron rep is getting a fairly *robust* email from me next week.

No volume control that I know of, but maybe you could make it an intermittent buzz? Might make it more noticeable.

As the title suggests, I have an NS8 project and would like to convert it for use in an NS5. CX-Designer (V3.3) can convert the project easy enough, but the contents of each screen are still at 640x480, where the NS5 screen size is 320x240. At first glance, it appears that I will have to modify every object on every screen to fit them in. Is there any sort of auto-resize function somewhere I have missed? Really hoping someone can say yes to that question, as there are a lot of screens.....

Apologies for the late response... I basically did what you suggested Scott, and grouped things together. Worked OK for some things, but not so much for others. Quite a PITA to do all the screens, but got it all done now thank goodness. One thing I did notice with the fonts in particular is that the actual display did not quite match the look of the screen on the designer, so it took a bit of fiddling around to make it look nice. Now it is done though, it is great to have the option of using an NS5 or NS8 without any underlying changes in structure, so very much worth the effort of the conversion.

I have a project coming up that will involve two PLC's (prob CJ1M) connecting to a single NS8 HMI via NT-Link (1:N High speed) on each of the serial ports. There will also be a need to have some amount of communication between the two PLC's. This will be a departure for me because usually I only have one PLC and one HMI in a system. I have discovered the Device Data Transfer function on the HMI and on first glance it would appear to be the perfect way to do this. I don't anticipate having a huge amount of comms between the two units: perhaps a block of 200 words or so on a specific trigger, and maybe 10 words on a 100mS cyclical basis. (Pretty vague specs at the moment, I know!) Would this be doable, bearing in mind that the comms is via the two serial links? Is there much latency bewtween requesting data from one host and receiving it in the other for example? I'm thinking it will be OK, but not had a chance to experiment yet, so if anyone has any experiences with this function (good and bad), it would be great if you could share them. Thanks.

Thanks Bob, had no idea that Omron produced a switch, will have to investigate. 640 words should be more than enough for this project, but good to know the limit nonetheless.

Good stuff, thanks for your suggestion. Always good to have an alternative and it has given me some food for thought.

Good point, didn't think about that. No experience with that either yet though. Simply a case of a single ethernet cable directly connecting each PLC and then configuration? No ethernet switch involved? If that is so, then it keeps my options open if I go for CJ2M's instead.

Don't worry about newbie questions. We all have to start somewhere. Whether or not you have a problem like this, you always have to bear in mind how things physically work in the real world. For example: If you turn on an output for a single scan of the program and expect a relay that is connected to this output to energise and do it's thing, then you will most likely find that it won't. (Depends of course on the cycle time of the PLC and the relay in question though.) A chain or belt driven item may well have an amount of backlash in the system, so that when you energise the drive, nothing actually moves until this backlash is taken up. Probably not much, but would be noticeable by the PLC if you expect a sensor to be uncovered the instant you energise the drive. Also be aware of how a PLC scan works. In simple terms it generally it follows the "Read the inputs, scan the program, write to the outputs" sequence. This means that you could toggle an output on and off a thousand times during the scan cycle of the program, but it is the state of this output at the end of the program scan that will get written to the actual physical output. In other words, a device connected to to this output will do precisely nothing at all if it is always turned off at then end of your program. Anyhow, I'll stop rambling now. Good luck with solving your problem!

Pretty hard to give much more than a general answer, but a few suggestions: Debounce the proxy switches. Make sure the switch is on (or off) for a constant amount of time before acting upon it. When the proxy switches are triggered you could latch a memory. This flag can be used to trigger all the things that the proxy switch would do, but will be immune to flickering switches. You could use this in conjuction with any debounce timer. Set up counters for each proximity switch. These counters don't have to control anything, just record how many times the switches were actuated. Be sure to make the pulses from the proxy switches one-shots. You may find that one/some/all of your switches multiple trigger sometimes when you don't want or expect them to. Set up a counters for each data transfer event. As above, they don't need to control anything, but simply indicate how many times transfers have occurred. Every time you need to transfer data, you can transfer it where you need it to go, but also copy the data to a stack of some kind. (If the data is not too big.) That way you can see if any 'blank' data is being transmitted, or none at all, etc.