Colin Carpenter
MrPLC Member-
Content count
471 -
Joined
-
Last visited
Posts posted by Colin Carpenter
-
-
Ah, solved it. I wasn't saving the profile, and when I tried to, I was waiting for it to prompt me for a profile name.
The trick is to write the profile name in the text box BEFORE you save it.
Many thanks for your help, that's going to be useful now.
Colin
-
Yes, I use the "Browse" utility a lot as some of these programmes have in excess of 35,000 steps and the I'm getting close to running out of M coils etc.
Just can't seem to work out how to print the cross reference. I used to do it a lot with old DOS Medoc, but have never been able to figure it out from IEC Developer (7.04)
Thanks.
-
BMOV D100 C1 K3
Wouldn't that move the values in D100-D102 to the counter values rather than the Set Points of the Counters?
-
I've never really used the print option on IEC Developer much, but I would like to print out a cross reference report to show me what variables have been used and where they have been used.
Obviously I'd print this to a PDF file, but try as I might, I've never yet been able to get a cross reference report out of the "somewhat confusing" printer options menu.
Has anyone ever managed to do this?
Thanks,
Colin
-
Have never worked with SFC, but I know that if you programme in ladder, then build and download, then rebuild all and verify, there's a very good chance that the programme will not verify correctly.
The programmes will both be "effectively the same", but the compiler may well have used different system variable numbers when it did the second compile.
However, the "show differences" will work and will show that only addresses have changed.
I've always ended up stopping the PLC and re-downloading as I hate programmes that don't verify correctly.
-
I assume that you have the programming software as you were able to get the fault code?
If you do not have the original programme files, then, unfortunately, I think you have a big problem.
The parameters file will need to be uploaded to the PLC from the programming software with the original programme files.
-
You could do it very simply with commands such as:
IF D8620 > D205 THEN MOVE D8260 to D205
IF D8260 <= D205 THEN MOVE D205 to D205.
You would just code this logic in ladder format and also determine when you wanted to reset D205 (MOVE 0 to D205)
How successfull it would be would depened on the speed of the cylinder stroke compared to the scan time of the PLC.
Say the piston took 1 second to cycle and the scan time was 5 ms, then the comparison would be done 200 times during the stroke of the piston, so the resolution of the maximum value attained would be quite good, but whether or not it's actually good enough depends on what you are trying to do with it.
-
The graphic shows what error 220 means.
Check that dipswitch 2 is in the off position if you don't have a memory card.
If DP 2 is on, then the PLC will be looking to a memory card for the parameters.
If DP2 is OFF, and you still get the error, then it's likely that the parameters file has disappeared and you will need the original software to reload the parameters and the programme.
Is there a low battery warning light on?
-
The battery is ok as some outputs are coming on, therefore the PLC has retained it's programme.
Don't ignore the obvious .... pull the communication plugs at the HMI and the PLC, squirt a small amount of contact cleaner into them and plug them in again.
Amazing how often some contact cleaner this will cure serial communications problems.
1 person likes this -
Not sure in GS Works 3, but in IEC Developer, I would open the two software versions in two separate IEC Developer windows and then you can just copy and paste POUs or individual rungs from one to the other.
You would have to pay particular attention to the addressing and naming of the Global Variables to ensure that addresses did not overlap each other, and so that the newly copied sections would compile properly.
-
5 hours ago, kaare_t said:No, it does not. The reason you cannot enter more than 32,767 is simply because of the software and not because of the PLC itself. As said: Signed/unsigned is simply the human representation of a bit pattern.
The PLC handles everything as bits, futher any operation is performed bitwise, hence 32,767 (2#0111111111111111) ADD 10#01 equals -32,767 (signed) OR 32,768 (unsigned) and the bitpattern for these two are the same: 2#1000000000000000. So again; the bitpattern is exactly the same, the only thing that "changes" is how you look at the number with human eyes through the software itself.
That is exactly why it is not interesting to monitor a PLC programs "signed" or "unsigned" devices in the monitoring software since the format is not "selectable". However in a HMI it is critical so that the representation of the bitpattern is as expected.
I agree with what you're saying, and I would imagine it could lead to some confusion to the uninitiated if the HMI was set up to display "unsigned 16 bit", so it would be showing 32,768 while the PLC would be working on a value of -32,767.
I just wondered if there was some obscure command in the software that could be used to tell an individual D register that it should behave as an unsigned D register, but I guess that is the reason for double integers at the end of the day.
I did come across a similar issue once with some software that someone else had written when a Q PLC was reading a 4-20 ma signal into an analogue input that was set up for 4-20mA = 0-12,000 bits, meaning that when the sensor was hovering around the 4mA mark, occasionally the PLC would read a negative value as the sensor dipped slightly below 4 mA.
The SCADA system was set up to read in an "unsigned 16 bit value", so instead of showing a slightly negative value, it would immediately jump from "close to zero" to a very large figure .... which led to an interesting graph!!
Changing the tag to a "signed 16 bit value" cured the problem.
-
No matter how long I'm in this game, I keep realising that I don't know things that I thought I knew.
I was called in yesterday to see if I could change some existing software.
A change in production had meant that a setpoint now needed to be entered with a positive value that was above the normal +32,767 that I normally use as the maximum that I will allow an operator to put in.
I know that I could have used double integers to overcome that problem, but in this case it would have caused addressing problems as all changes would have been online, and I eventually sorted out an easy fix with other scaling factors, but it made me realise that I'd never stopped to think about the D registers in a Q series PLC.
I noticed from the HMI that I could select a "signed 16 bit" or an "unsigned 16 bit" type for the D register, and I know that an unsigned number can be 0 to 65,535 and that a signed number can be -32,768 to + 32,767, so I considered selecting the "unsigned 16 bit" option so that I could enter a value greater than +32,767.
But then I stopped to think about how the PLC would handle that number when it arrived, in other words, would it always view a number greater than 32,767 as being a negative number, or is there a way of telling the PLC that this particular D register is holding an unsigned integer, and therefore that the 16th bit doesn't signify positive or negative?
I'm pretty sure they will always be "signed integers", but wonder if anyone has ever proven this wrong?
-
Yes, I realise what he's got, but also realise that the thread title refers to a converting from an FX to a Q, and he also says:
"Actually I am working on Indexing machine where I am facing scanning problem of Q series PLC.
As we are taking feedback from Absolute encoder and converted in 0 to 360 degree and I have fire out some output depends on encoder current value/degree "
... I was just trying to point out that the high speed inputs of the FX and ABSD command are designed to do exactly what he is trying to do, without facing scan time problems.
-
I looked up the FX command that is used to read from a high speed encoder to give a number of outputs with varying dwell agles etc and the command is ABSD (Absolute Drum).
Incredibly powerful and looks exactly right for what the OP is trying to do ..... however not sure if the command exists in other PLCs outside the FX range.
ABSD can only be used once in the code and is tied in with interrupt commans in the PLC.
-
It's one of the problems that I keep running into as I change out old "standalone" FX series PLCs to run on the larger Q series PLCs that are linked to SCADA systems and have more access to what's going on elsewhere in the plant.
I tend to look at FX PLCs and thinks "old - needs replacing", but in reality, the high speed inputs that exist on them are incredibly useful and expensive to replicate on the Q series, with high speed counter cards costing a considerable amount of money.
There are also other functions in the FX PLCs that are designed to take high speed inputs from rotary encoders and turn them into "virtual" cams with numerous lobes and variable dwell angles. It's no wonder that whenever you open the panel door on a rotary filling machine, there's normally an FX staring back at you :)
I must admit that I've looked at interrupt routines several times in the past, but have always chickened out and bought a high speed counter card whenever the problem has arisen.
PS. In the past, I've even used small FX PLCs to count high speed inputs and hard wired an output signal to the larger PLC as a cost effective means of overcoming this problem.
-
You need to check that the values that you will be reading and writing are compatible with the types of blocks and how they are set up in the software.
For example. the FX2N-8AD can (from memory) read in a 4-20 mA signal as 4,000 to 20,000 bits, so a midpoint value would read a value of 12,000 bits into the data register.
Not sure what the maximum bits are that you can send to the FX2N-2DA, but would doubt that it would be as high as this, so check the manuals for each expansion block carefully and ensure that the "bits are consistent" with what each of the blocks can handle.
-
As Gambit has said, the address U1C\G20480 translates as Buffer Memory 20480 of the special function module residing at Hex Address 1CO.
I have a special function module that enables the a Q PLC to take its place on an older A series Melsecnet system ,and bumped into this method of addressing when researching the code I needed to write. For example, my module sits at Hex address 2C0 and I have to write U2C\G1024 to access buffer memory 1024.
-
I find that a very good piece of software for creating graphics is Xara Photo and Grahic Designer, which is a vector graphics package that does a whole lot more as well.
Not that expensive, but very, very good and can export the finished graphic in a format that most HMIs can import.
You can download a full trial and run it for a month before purchasing.
-
Glad it was of use.
Have never come across the MAXIMUM comand before, but would assume that it takes the maximum value that it finds in all those registers shown and puts that value into the GT block. If that maximum value is greater than zero, then you know that at least one of the registers is non zero.
Sweet way to do it. Well done.
-
15 hours ago, Jim82 said:That was my first plan to do.. but im going to use a range from D0 to D300 so its going to be quite alot of adding... ;)
Thats why i asked you guys if there is a function that dont need to specify each data...It's not as bad as you think.
If you drag in one of the "ADD "function blocks onto the page then click on it, you should find that your cursor turns into a double headed arrow that enables you to drag the bottom of the block downwards and add extra inputs. This enables single function blocks that would add up (say) 10 D registers to give the result.
If I was doing it, I'd make one of these that added 10 variables together (say D00 to D09 and enter them as D00, D01 etc) then copy that block and use "find and replace" to change "D0" to "D1" which would then give you a block that added D10 to D19. Do this eight more times and you should have the sum of D00 to D99. Then copy all ten blocks you have created and use "find and replace to change "D" to "D1" and you should then have the next one hundred blocks. Repeat ( find and replace "D1" with "D2") to get the next one hundred etc.
Would imagine it might take about half an hour to programme ... it's only 30 function blocks and you could put them all in the same "rung" and have all 30 results feeding into an ADD block with 30 inputs which would then give the single answer.
Would look quite elegant .... a bit like the wiring diagram of a CPU :)
1 person likes this -
Maybe not quite as elegant as it might be, but why not just add up the values in the range D20 to D30, put the answer into (say) D31 and do a single compare
of the answer.IF D31 equals 0 THEN ......
If true, then there are no 1s in any of the words from D20 to D30.
-
I have great respect for the technical knowledge that you both have, but I have to say that in 30 years or so of connecting 0V to ground, I have never had a single problem as described. I have never had any digital input cards go bang or fail to work properly. The only noise issues I have ever had have been with an RS485/422 cable connecting an HMI to a PLC that actually passed though an inverter panel (solved with a braided "Farady Screen" , and once I had a PT100 temperature probe that would read wrongly whenever any one of the installed inverters started up. This was solved by fitting a probe with a 4-20 transmitter on the actual probe rather than in a remote panel. I have actually seen an electrician connect a phase to earth .... or rather he was making up earth tails and one of them flicked momentarily onto an exposed phase terminal. Big flash, lots of UV, breakers went out as you'd expect but no problems at all with any of the PSUs or digital inputs. The only "ghost" inputs I've ever experienced were on an FX2N without the S/S terminal tied down to earth, and these were exorcised when it was tied down. I've never known a Mitsubishi PLC get a corrupted programme even when welders have been striking up their TIG welders on the stainless panel that the PLC was installed in. Also, tying the 0V to earth makes it a lot easier to find live 24VDC signals out on the process floor as you can used an earthed chassis as the negative for your digital multi meter. It does seem strange that all us UK users say the same ... wonder what's different? -
I'd agree with NIghtfly .... connecting the 0V to earth is our standard as well. And check that the 0V terminal on the PLC is connected to earth and that the S/S terminal (because of this) is also connected to earth. I once left the S/S terminal not connected to anything and the inputs had a mind of their own, going on and off at will. -
Thanks for all the replies, and sorry I haven't got back sooner .... been on site for a couple of days. I managed to get it working today, and once again this shows that you should never trust anyone. I'd been trying to get SCADA ( which is actually the brilliant Prodigy package) to connect to the PLC using a TCP-IP address of 192.168.16.252 which was the one that the IT manager had set up for me after I'd given him the MAC address of the E71 card. Today, I tried again and after setting up an ethernet hub close by so that I could connect the PC , I "remote desktopped" into the SCADA PLC to do a ping test of 192.168.16.252, and it was successfull. "That's good" thinks I, but then I realised that I hadn't plugged the patch lead into the PLC yet, so immediately I realised that something else was already on this IP address and was the cause of the problem. Saw the IT manager, got another IP address ( this one did not reply to a ping, so there was nothing else out there) and the PLC immediately starting talking to SCADA as sweet as you like. Never assume .... Thanks again
EDesigner 7.5 drivers
in Mitsubishi
Posted · Edited by Colin Carpenter
clarity
As an update to this thread, today I had to find out how to make sure that the PLC comms drivers in E-Designer were identical across two laptops and after a lot of head scratching and searching, I finally managed it (both laptops running XP Pro.) Below is how to do it.
1. E-Designer makes a lot of entries in the registry telling the software where to find the drivers and what the driver names are.
2. The actual names of the driver files seem to be consistent and do not change. Only the contents of the files changes with the versions.
3. The driver files and information are stored in the folder C:\Program Files\Common Files\Beijers Shared
4. On the second laptop (the one you are trying to update) rename this directory as Beijers Shared Old ( or something similar)
5. Copy the C:\Program Files\Common Files\Beijers Shared directory from the laptop that you want to clone and paste it into the C:\Program Files\Common Files directory of the second laptop that want to be identical to the first, then reboot the second laptop and they should be identical.
Worked for me anyway, and the problem I was having was that all my screens were using a Q/Qna E71 driver (v8.0) that is no longer available as it has been superceded by the MC protocol. But I am a huge fan of the saying "If it ain't broke, don't fix it" ...... especially on running plant that cannot afford any down time.