Sign in to follow this  
Followers 0
Guest John Smith

HSC reaching maximum

6 posts in this topic

Hello all you Mitsubishi programmers. I am fairly new to programming, I have done a few programs that I am quite proud of but not using much more than bits timers and counters. Now I have a problem that I am struggling to find a solution to. I am doing a research and development machine and I have an 50 PPR encoder connected to X0 (FX0n) I am using C235 to count these pulses. During the cycle of this machine, 4 valves have to operate at set counts (set by hmi) So far no problem: But if valve 1 has to open at count 100 and go off at count 300 then valve 2 has to open at count 500 and go off at count 700 by the time valve 4 has operated, valve 1 needs to come on again. (I think I can do this) but the real problem is, at no point during the running of the machine is there a gap where I can reset the counter. This means the counter is rising all the time. I am telling the valves when to operate by MOVing the value from the counter, adding the count that the valve needs to be on for, then comparing that value to tell it when to go off. But I can see in my logic that the counter (even though it is 32 bit) will reach its max count while still doing MOV’s and CMP’s and it will not only be looking for a number too high for the plc but I suspect it will fault out when the counter reaches maximum. These valves are spray head valves spraying product as it goes beneath them continuously. I am stuck on how do I MOV all the data around and keep the counter from reaching max

Share this post


Link to post
Share on other sites
The correct way would be using an encoder with one revolution per machine cycle and resetting its HSC by encoder zero pulse.

Share this post


Link to post
Share on other sites
I am not sure what you mean - but its probably my explanation. let me try explain further. At any one time - all four valves are waiting for their signal from the counter but it does not go valve 1 to 4 finish. Depending on what count the operator will set for each valve and the distance between these valves as the product passes by underneath them, valve 1 will be coming on again before valve 4 has finished. (otherwise there will be gaps.) say valve 1 sprays for 100 counts, valve 2 has a preset value of pulses before the product reaches it. It then (say) sprays for 100 counts too. This goes on until valve 4 sprays. But by the time valve 4 is spraying valve one has to spray again. The cycle is continuous and not really a cycle. Each valve has to be aware what the preceeding valve sprayed + the gap then spray itself. Valve 4 for instance has to add up the first 3 valves totals + gap from valve 1. This is to produces a continuous line of sprayed product. If I reset the counter and valve 2 (say) is looking for the value 350, it will not get there. Please ask more - because I am sure I am not good at explaining it properly

Share this post


Link to post
Share on other sites
Costly colleague this this is a dilemma. It is situation, to my knowledge, exists a restraints to implement. The PLCs do not they possess adequate resorts to treat information in high speed, you are not the the only one. Motive to which awoke interest in open this post. FX0N not has FNC 63 -Incremental Drum Sequence you go ideal instruction. I will not supply a logical solution therefore the that MYSELF possess for this case, would operate in function of the time of SCAN. Case the smaller time of answer, action from the machine be more less than the SCAN, not applies-itself. The correct one, apply the trigger in the INPUTS X0, X1,X2, X3 and utilize a counter for each valve. If stayed, bothered, do not concern. I believe that this situations are the motivate, I expect that programmer best know, come support and we will be able to build the solution.

Share this post


Link to post
Share on other sites
Here's one approach you could consider... (untested but it seems right) [Edited to remove rather large mistake] ;) Whenever you need to re-calculate a target (eg. the user changed the setting or a different spray head affects another one or whatever), you must store the current encoder count as a positive number. If its already positive, just store it. If its negative, convert it to a positive by just clearing the sign bit (the highest bit) and then store it. DON'T do a 2's compliment on it. You can clear the high bit by simply doing a "WAND H7fff" for 16-bit or DWAND H7fffffff" for 32-bit . Now add the appropriate number of pulses to this same positive number and store that as the target. Now get the carry flag which was affected by your addition and store it too. The carry flag will be set if your addition caused an overflow. That's telling you that your encoder should also overflow before it will be valid. Now on each subsequent scan you need to check to see if the target has been met. Note: "current count" in the following means current encoder count after clearing the sign bit. The target has been reached (or past) when: if the stored carry flag was low AND: (current count < stored count OR current count >= target) if the stored carry flag was high AND: (current count < stored) AND (current count >= target) You'll do all of this for each separate spray head. This may seem like a lot of work for the plc to do but each operation is fairly fast to execute. Its much better on the FX2n. It'll do this type of stuff like lightning. Regardless, it probably doesn't matter in your case if you miss a target by a scan or two. Jim Rowell Edited by JimRowell

Share this post


Link to post
Share on other sites
Thank you for your answers, they gave me many things to think about. It was a dreadful feeling thinking I had bitten off more than I could chew. :) One thought that I had before I wrote here was that I might have to use 4 seperate encoders, which I really didnt want to do. But I have now tried using the one encoder input and looping it to 3 other inputs (as suggested) (X0 to X3) and using a seperate HSC for each. I was worried about combining so many HSC's as I read there was a maximum frequency that the plc could take. I couldnt really work out wether I was exceeding it or not, so I just tried it. The machine runs fairly slow and the encoder is only 50 pulses per rev. Well, it works, and the counters catch every pulse. So now I am altering my program to suit. (lots of maths ) I can now move the data about and reset each counter when needed One funny or at least unusual thing I found. The pulses are coming in at about 30 to 40 per second on each input. So I would have expected the input light to flash very fast (or seem dimmed as the pulses come so fast) But no. The inputs led's X0 to X3 all flash together at about once per second. When I first saw this without checking the program, I thought it was not going to work. But it never misses a count and these four inputs flash on and off at once a second all the time the machine is running. Thankyou chaps for all your help. You got me over a hurdle that at one point I thought was insurmountable. I am moving up the programming experience ladder albeit with a aching head hehehehe

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0