Maninashed

Thanks for your input Kratmel. I'm using version 9.8.95 Build 0 which I think may be the latest. Interesting point about the successive steps of movement and the idea of latching the state=5 condition. I'll give it a try and report back. In the meantime I'm awaiting a response from Unitronics tech support - I opened a support ticket yesterday. Thanks again and best regards.

Anybody with any knowledge?

Forgot the important bit: The PLC is a V430-J-TR34

Hi All, I am successfully executing PTO Move instructions. I am confident that the movement is happening correctly - I can see the motor and the attached mechanical components moving, I can see acceleration, I can see deceleration and the mechanical assembly moves the correct distance. The movements are quite long - approximately 5 to 10 seconds. At the same time I am examining the Status Message and Status Bit outputs from the PTO Move instruction in 2 places: 1. Within Visilogic using the online test functionality 2. Using variables displayed on the HMI screen During the movement I am observing values for the 2 output variables of: Status message=0 "Idle/OK" and Success=1. These values do not change before, during or after the movements, even though the movements are of many seconds duration. The help file and the software manual show that the expected Status message is 5 "Currently in motion". Is it correct that I am seeing Status message=0 and Success=1 during movements? If it is indeed the case that a successful movement does not cause either of the PTO Move instruction output variables to change as I believe I am observing, then am I correct in assuming that neither of these variables provide the means for determining whether a movement is in progress? Thanks in advance.

Hi All, And here's another PTO-related peculiarity which I'm hoping somebody might be able to answer (query number 8 in a list of emerging unknown PTO things): 8. After doing repeated PTO Moves successfully (with successful PTO Move status and success outputs) PTO moves then fail with a status message of 3 "Channel not initialized, or Vision outputs do not support function" and all subsequent PTO Moves fail in the same way until the power is cycled. The Vision outputs definitely do support the PTO functionality so the error message implies that the PTO channel is not initialised. It definitely was initialised (previous PTO Moves worked correctly) so my question is: Is there a requirement to repeatedly do a PTO initialisation (either a PTO Configuration or a PTO Set profile) and if so what are the rules? Does anybody out there have experience in the creation of a complete and successful Vision-based application using PTO functions or is there only experience with exploring and experimenting with the PTO commands? Yours hopefully.

Hi Joe, Thanks for the input. I did indeed see this in the last couple of days and also the version for its V350 friend. Whilst they were educational they didn't give any insight into the sort of problems I'm seeing. I've just had a fairly intense and long day trying to make headway and I've arrived at a place where the PTO is mostly behaving itself in controlling 2 steppers, but only when set up with configuration and operating parameters which it decides are agreeable. I'm coming to the conclusion that some combinations of configuration and operating parameters appear to produce error status messages from several of the PTO commands which are unexplained and unpredictable. I think that I'm simply unfortunate in that my application ideally wants to use problematic combinations so I'm having to make adjustments in my code to get to a robust place. I have a support ticket opened with Unitronics regarding what I'm discovering and I'll post the outcome and any further discoveries I make if it seems that it might be helpful to others. In the meantime, it's still a mystery....... any further wisdom out there would be most welcome. Thanks again.

And another peculiarity I've just encountered is: 7. When executing a PTO move, the resulting Status output is sometimes 0 "Idle/OK" whilst the Success bit output is also 0. The help files show that the Success bit should be a 1 when the Status is 0. With some other implementations of the PTO move, I have achieved Status = 0 and Success = 1 as expected. Does the occurrence of 0 on both outputs indicate some other state that I haven't yet discovered?

Hi All, I have a few queries about the operation of the Vision PTO system. I've looked in the help files, pdf help files and online webinars but can't find the answers. Any help with the following would be gratefully received: 1. My understanding of the "Units" and "Pulses" settings is that for example if you had a machine with a linear movement you wished to describe in millimtres and where 100 pulses from the PTO resulted in a movement of 1mm then the correct PTO Configuration settings would be Units = 1 and Pulses per Unit = 100. My question here is: would settings of Units = 2 and Pulses per unit = 200 produce the same results (1/100 being the same ratio as 2/200)? 2. In PTO Set Profile settings, in what units are the values for Start/stop velocity and maximum velocity? I'm guessing pulses/sec, mm/sec (or whatever units have been set up in PTO Configuration) or perhaps something else? 3. When executing PTO Set profile, what does status message 5 "Out of range" refer to? 4. The help file section for PTO Set profile refers to 4 ranges of "minimum and maximum ranges for your motion profile". Are these ranges assigned automatically depending upon other parameters already defined or is there somewhere I haven't discovered where these need to be explicitly defined? 5. When executing a PTO Move I've encountered a status message 5 "Currently in motion" despite the fact that I ensured that the previous movement had completed before starting another (by virtue of waiting for a status message 0 "Idle/OK" and Success bit = 1). Is there an explanation for this? 6. Again when executing a PTO move I've encountered a move being prematurely terminated together with a non-zero staus message (can't clearly recall which one but I think possibly 1 "Configuration is invalid" or 4 "Absolute movement cannot be performed"). This suggests to me that some movement errors are only discovered mid-movement rather than before the movement starts. Is this correct? Thanks in advance for any assistance.

Hi All, I'm currently building a machine control application involving two axes of stepper motor control using a V430. Does anybody know if there are any safeguards which should perhaps to be written into the user's code to guard against an absolute PTO move attempting to move to a position which is identical to the current position? That is, current position and destination position are identical so no movement is required. Does the PTO move function handle this robustly in all cases or is it safer to look for the destination=current case beforehand and then to avoid executing the PTO move instruction? Thanks in advance.

Splendid stuff -feedback from the user straight into the user documentation! Thank you both.

Top-flight programmer huh?! I feel honoured even at the very thought of being a top flight anything - thanks for the boost! PM comment noted.👍

Ah! It becomes clearer. Whilst I knew there was a distinction between Standard and Enhanced I didn't realise that the user documentation was based upon the Standard variant. I think that some of my trouble is that I generally seem to push things like PLCs to their limit and so I get into the more tricky areas of operation which might show up the holes in the documentation or perhaps might need a bit of assistance from a wise one on a forum somewhere. Still, I always aim to turn out a blindingly good product and so I think that the effort is worth it in the end.

I agree - the help file is definitely a bit fuzzy in this area. Not least because it seems to refer to some previous version of Visilogic. This is immediately apparent by comparing the image you've just posted from the user documentation with the image I posted from the latest version of Visilogic. I've often wondered whether I'm simply behind the times and if there is more up-to-date documentation out there somewhere. I've gone hunting for it on several occasions without success. It's a great shame really - In my opinion the Unitronics combined HMI/PLC devices are rather excellent and stand in a class of their own but the documentation is lagging behind somewhat.

Exciting update...... (exciting for me at least) After some excellent tech support from our UK agent (I4Automation - thank you Tony ), the problem was identified as the bit variable I'd randomly selected for the Link field in the ASCII string definition box. I don't need the element to be linked to anything but apparently you can't define an ASCII string element unless a Link is specified (the 'OK' button is greyed out if none is specified). I simply chose the bit which is set to indicate that this particular screen is being displayed thinking that it would always be '1' whilst displaying this screen and that all would be well. If it is changed to an unused bit variable the flicker goes away. This seems like a pretty obscure nugget of information so I hope that some other frustrated person who is plagued by a stubborn flicker might benefit from this. Thanks again and all the best.

Hi Ausman and Flex272, Thanks for taking the time to reply. I can confirm: 1. The display is not being called multiple times. The calling rung in the ladder definitely shouldn't call it more than once and setting watch points confirms that it is indeed only being called once. 2. Tried the blank project download, initialise, reset, then proper project download, initialise, reset. This didn't cure the flicker. 3. Tried many variants of spacing and sizing of the elements. This didn't cure the flicker. I also looked for any invisible elements which might be overlapping - there are none. Whilst moving the elements around, when swapping the positions of the two ASCII text fields, the flicker remains with the same element. I also tried deleting the flickering element and then recreating it from scratch. Initially it flickered, then I resized it a little and the flicker disappeared. Good news I thought until I resized it again to the size I'd actually like it to be and the flicker reappeared. I've been unable to recreate the non-flickering case by further resizing. I also tried deleting the flickering element then copying and pasting the other (non-flickering) element. This resulted in the copy flickering. So, no further forward and extremely perplexed. Thanks again.