Q SERIES TRANSIENT TRANSFER DO AND DONT

[Mitsm83]

Hello all,

I have 7 Q series PLCs on a Melsec net/h network, Ladder Programming none of that fancy smancy ST stuff LOL. Were running the QJ71LP21-25. Now to keep it short I have used all most all my devices in my Network Range Assignment. I can not set up low speed range as I do not have enough Link relays and registers at all stations. No memory for more devices just trust that I can not do it... However I have an abundance of File Registers ( no I cant buy B or W in the PLC File params, well I can but it wont help because only one CPU is UDE the rest are H.)

I have a project in which I must see about 50 words for each Station at every Station. I figured while I am setting up a Transient Transfer I will make a bunch of extra room for future updates and junk.

My answer good or bad, is to set up some Send/Recv commands and do some Transient Transfer. I think I have it just about all figured out just a few questions.

I have two manuals I have been getting my info from Q MELSECNET/H Network System Reference Manual ( I think SHNA080049)  and the Melsecnet/h training manual. 

1.Any one have any better manuals that better cover transient transfer? Or that are new enough to mention GX Works2 instead of Developer?

2. Is there a max device for each send/recv? (I keep thinking it is 980 per station but no idea where I got this number)( I will increase the max # of transients in the supplementary settings under network range...)

3. Any precautions or advice like, Hey don't do this, I did this once and....

4. It looks like as long as I use different logical channels for each station I should be able to send and receive multiple "messages" at once with no error?? (I will test this and look for the "no room in receive buffer area f222 error) 

5. Will this slow down the Cyclic transfers (I will be watching the SW006D and so on to make sure it does not slow my regular transmission down.)

6. I will be using several special relays and registers in the program of course. Any I should use that are not obvious?  

[kaare_t]

Hi!

Not sure if I understood your "original" problem, have you used all the points you can in the Network Range Assignment??? Maybe you could take some screenshots, alternatively upload your code for the master (or just remove all code, and upload the parameter configuration only)?

1. I don't think so, but GX Developer and GW2 parameter settings are basically the same so it should be good
2. According to my manual (the same as you have), the maximum number of words in one transient transmission is 230 between Q systems
3. Never used Transients, but it should be OK as far as I know
4. Should probably work -> Test it
5. Probably a little bit since you will be using a little bandwidth -> Test it
6. Use whatever you want

[Mitsm83]

Thanks for the reply.

I will upload some screen shots Monday as I can not access from home and have none of the code with me.  Maybe I can explain a little better though.

Yes, I have used all the devices in the network range assignment. They are used in the original code to "hand out" recipe data. We are not using the max at each station, so my first thought was to increase the range for each station but this would require changing the code at each station for the recipe stuff. That is a task I am not willing to take on as it is 1k words each recipe spread unevenly across 7 stations it would be hard to change the first word for each station if that makes sense. I wish at original set up the coders would have left a larger area for spares. I would have liked to see 20% spares at each station.... but as they say here in the US wish in one hand piss in the other see which one fills up first. 

My next thought was to use low speed range as it is not set up with any devices. I found though, that at two of the stations they used the W and B for stuff non link related so all the devices are used. Another problem with using the low speed is I was told all CPUs must be universal type. I only have one that is UDE the rest are High Performance. 1 Q6UDE (Master) 4 Q6H and 2 Q12H.

I was really hoping someone would come and say it will work, but one time I did //EXAMPLE and it crashed two months later so avoid //EXAMPLE and it should be okay.

I have a test bench set up with two stations I think I will code it to mock my set up and monitor it for a week or so to try to rule out any bugs. 

I will definitely update with my results for anyone who reads this in the future. 

[kaare_t]

16 hours ago, Mitsm83 said:

I found though, that at two of the stations they used the W and B for stuff non link related so all the devices are used

I see, but you can setup multiple "Refresh Parameter" transfers to spread LB/LW across different areas in the CPU.

16 hours ago, Mitsm83 said:

Another problem with using the low speed is I was told all CPUs must be universal type.

I don't think that's correct. Low-Speed transfer between CPU's are restricted to universal series only, but the MelsecNET/H master module are able to setup low speed LW/LB areas for transfer. It's the same Control module.

 

 

As mentioned, screenshots would be nice. Even better sanitized source codes (just remove all code, and include the Parameter section in the source code). It would be nice to have for at least two stations (Control and at least one Normal).

 

[Mitsm83]

Control Station 

No comments or ladder as had to get down to attachable size to post. 

Master.gxw

[Mitsm83]

1 of 6 Normal stations, removed local comments and ladder. Also removed my Ethernet stuff for both. 

Normal 1.gxw

[Mitsm83]

Also,

thank you for helping.

[kaare_t]

No problem!

I've attached some screenshots of a setup I think might work for you:

1. Control Assignment: Assign LowSpeed area for each normal station
2. Refresh Parameters for the Master station (you can divide each area if you would like to avoid having one big area)
3. Refresh Parameters for Normal station1 (I've included only "relevant" devices here for this station, you can also assign the whole area if you wish)
4. Refresh Parameters for Normal station2 (I've included only "relevant" devices here for this station, you can also assign the whole area if you wish)

It's been some time since I worked with MelsecNET, but I think this should do the trick. What I used to do was to setup an excel sheet or something with a cross-reference so that you are able to see which devices are needed in which station. Often, there's no need to exchange all data between all (normal) stations, so you can limit the number of devices used in each station by setting up a more specific "Refresh Parameter" in each station, enabling you to only read/write the relevant data.

The reason I'm suggesting to use parameters by the way, is to avoid a mix of both parameter settings and coded transmissions. It can often lead to confusion if you (or others) are to debug the programs in the future. It's always a mess when mixing two different "styles" of source code in my opinion.

Try my suggestions out, and let us know how it works out.

[Mitsm83]

Thanks,

I will try this as soon as I get a chance. Low Speed range was my first solution but was told by a trusted source I had to have all UDE CPUs. After trying it on my test bench I can say he was wrong and you sir (or Mam) are right!!!! I am sure you are used to that by now haha!!

I agree with the one type of transfer. The regular maintenance group already has problems tracing data through one type of transfer. I guess at least I was going to use SEND RECV and not ZNWR so it would have been some what traceable.

I was at Mitsubishi Automation yesterday for some unrelated stuff. I showed off your suggestion and bragged on how friggin cool this forum is. What an amazing tool the internet can be!!!

Thanks again,

One more question,

I was also told I would need all Universal type CPU to migrate to IE Control or IE Field, Do you know if this was correct? 

 

[kaare_t]

No problem

On 27.4.2017 at 3:49 AM, Mitsm83 said:

I was also told I would need all Universal type CPU to migrate to IE Control or IE Field, Do you know if this was correct? 

 

Partially correct: You can run CCLink IE Control on the regular CPUs (Q02(H)), but NOT CCLink IE Field! In other words: To run CCLink IE Field, you will need an Universal CPU. So here's a possible solution: Run CCLink IE Control Network (optics, ring network) between all your CPU's, and setup one CPU as a gateway between CCLink IE Control and CCLink IE Field.

You can either use your existing Universal CPU as a gateway, or alternatively buy a new Universal CPU (or better a RxxEN CPU with built-in Ethernet AND two CCLink IE Field ports). Note that you'll need GX Works3 to program the R CPU. As a personal view, you should really test out CCLink IE Field on a RxxEN CPU, it works like a charm. 1Gbit interfaces where you can choose between star or ring network on regular copper Ethernet. It works great for peripheral devices (and would also work great as a control network if you don't want the optics, or ring network) - just my personal opinion.

I would just like to note that I myself have not tested CCLink IE Control network on the regular CPU's (non-universal), but according to my documentation and GX Works2 software, it should work fine with CCLink IE Control on a regular Q CPU.