caslen

Hi Sina, The Ctrl-A is definitely called before the &1B1R, I only called it to ensure that all the motors were in a known, active state before I try to run the motion program. As a temporary solution I have simply removed the Ctrl-A. One other thing that I think is significant - I was running with I5113=0 (CS1 Segmentation time) which seems to be the default, since I set this to 10, I have had no problems at all since doing these two things.

Hi, Thanks for the reply, the loop is in the C++ controlling software but I think I may have solved the problem already. In my software I upload the motion program and then immediately try to run it. Before I issue the '&1 B1 R' command I send a Ctrl-A - it seems this is the problem, sometimes this returns 'Response[0]=7' ( GetResponse() ), removing the Ctrl-A command seems to cure the problem although I am still testing to prove it. I do not know why this would cause the error I had though.

This is a new system with a PMAC and 6 Macro drives in a ring - it is also new driving software... I have a simple motion program which is repeatedly executing:- CLOSE END GATHER DELETE GATHER DELETE TRACE OPEN PROG 1 CLEAR LINEAR ABS FRAX(W) TA700 TS100 F100 DWELL0 P96=1 X500Y130Z0W500 DWELL0 P97=1 CLOSE Only the line 'X500Y130Z0W500' changes as the machine moves, Occasionally the cycle stops with Motor Status Bit 11 Block Request set, the motion program appears to have uploaded correctly and an '&1 B1 R' command in the terminal window runs the program normally. What is the likely cause of the Block request bit being 'stuck on'?

Scale factor is set by the kinematics I think hence I have :- #1->I in the coordinate system. I5190=1000 I5198=1 (already set low) I have already run this as a regular motor and it works fine - so by your last statement it must be the kinematics, they are very simple:- &1 Open FORWARD Clear Q4=P1003 Q5=P1003 Q6=P32 Q1=0 Q2=P4/10.0 Q3=0 Q7=P1/1000.0 Q8=P2/10.0+Q4*cos(Q2) Q9=P3/10.0+Q4*sin(Q2) CLOSE &1 Open INVERSE Clear P17=Q4*(P1003) P18=Q5*(P1003) P4=Q2*10.0 P14=P2 P1=Q7*1000.0 P2=(Q8-Q4*cos(Q2))*10.0 P3=(Q9-Q4*sin(Q2))*10.0 P32=Q6 CLOSE I have checked that the scalings match - maybe I missed something so I'll check again, its finishing time here so it will have to be tomorrow, thanks for the help, [quote='Unit101' pid='853' dateline='1290446659'] What is your axis scale factor for the CS ? #1->????X What is the timebase for your CS ? I5190 = 1000 = seconds Remember your Feedrate command is going to be the scale factor * counts / timebase units. So if you have a scale factor of 10 and time base of seconds a feedrate of 100 = 1000 counts / second Try setting your Feedrate command to a very low value and see if it works. Try setting your I5198 to low value and see if it works. Also look carefully at the Kinematic Subroutines, in here the scale factors could also be mis-applied and giving you some big value that the motor cannot achieve. In fact to prove it is not in Kinematic, turn this off and just run it as a normal motor. If it works then issue is in your Kinematic routines. [/quote]

I'll try this out tomorrow, I have another problem at the moment that I'm trying to sort out - a motion program that won't run at the correct speed! The program is very simple:- OPEN PROG 10 CLEAR LINEAR FRAX(X) F(P1000) TA500 TS100 X(P1001) DWELL0 CLOSE I set the speed in P1000 and the target position in P1001 but when I run it the velocity increases well past the maximum until it faults out with a following error. My feedrate limits are set as far as I know to sensible limits. The X axis is defined as a kinematic axis using FORWARD and INVERSE but is not 'connected' to any other axis - it is a basic linear axis. Any ideas? Are there any other speeds or limits to set in this case? regards [quote='Unit101' pid='851' dateline='1290441963'] Yes I agree 110% that need to use caution with blocking logic like a while loop. I did not show more code that I would normally have for timeout. I don't like using just timers to wait a few seconds... this is quick and dirty code fine for testing but in real production can be very costly wasting time every time or not working well because time is too short. Much better to work with real events such as monitor the CS In position then use time. However need to prevent it from blocking so I would add some logic to timeout in case of problem. I like to dedicate one timeout counter to each plc, since each plc could have only one while loop at a time blocking... so I do it like this... #define plc6_counter P41 plc6_counter = 1 while(M5187 = 0 AND plc6_counter < 50 AND fault = 0) ;here inside the while loop Delay1 = 1000 msec1 ;wait for 1 second endwhile plc6_counter = 0 NOW in a different PLC - that I only use for Timers/Counters... this PLC is never blocked by while loops. It is used to increment counters every so often... so they can be used as above. In this PLC I would increment the plc6_counter by 1 every 10th of second IF it is greater than 0. So by setting to 1 - activates it and the timer plc will increment by 1 every 10th of second. So the above while loop would exit with timeout after waiting about 5 seconds at the most... after exiting you can look at the counter and determine if it timed out or all is cool and act accordingly. There are for sure many other ways to do this... but this is my basic project logic used in all my programs. I be glad to send you more example code of the timer plc if you need. [/quote]

Sina, I've done some checks with feedrate and the jog ribbon but I don't see any correlation with the problem I have - sometimes it happens sometimes it doesn't, whether or not the jog ribbon is open or not. Unit101, I appear to be running successfully with "&1 H" followed by "Ctrl A" you suggested that I monitor M5187 after the "&1 H" command to ensure the motors have stopped. I'm a little nervous doing this since any 'while' loop of this nature is potentially non-terminating. Under what circumstances would "&1 H" not stop the axes after, say, a couple of seconds? Or is it that it is just a catch all for any very slowly deccelerating axes? Cheers Steve [quote='Sina' pid='849' dateline='1290191241'] One thing I have seen that the Isx98 doesn't follow the commanded value from % command and customers claim that it does something that they can't explain, was caused by PEWIN32PRO and PEWIN32PRO2 Jog Ribbon tool. The way that this tool is implemented, it can't tolerate any change in feed rate override from outside the Jog Ribbon and it would cause problems. Make sure that the Jog Ribbon is closed and try the test again. [/quote]

The nature of the machine is such that it is common for the operators to want to abort the cycle part way through so it is normally not neccessary to kill the motors, I think a 'Hold' and 'Ctrl A' would be sufficient. Some of the machines are quite large and have a lot of inertia and so a sudden stop feels like the thing is shaking itself to pieces hence the original attempt at setting the feedrates and messing with M5198 to try to control the stop a bit better. I think with the hold command all this should be taken care of providing Isx95 is set up properly?

Thanks for the quick response, I5198 is used in two areas, the first as I have already described is to aid in a controlled stop. I will use your suggestion of the 'Hold' command to replace this - one question, if I want the stop to be permanent ie to prevent the restart facility should I issue a CTRL A after the H? The second place in which I5198 is used is in feedrate control while in cycle - I am assuming from what you have said that I would be better off issuing a '%' command to control the feedrate rather than messing with I5198? In the meantime I will look at the hold command in the manual as you suggest - once again thanks for the help. [quote='Unit101' pid='844' dateline='1290176900'] Hello, First I5198 is not intended for this purpose - it is the CS Max Feedrate value. It is used when running motion programs to setup a Max value usually by the machine builder so that no user will exceed this rate in his downloaded motion programs. Using it for changing the feedrate WHILE the program is executing will not give you the results you want when you want them. It does not effect ALL motion commands and often when you change this value other motion cmds have already been processed, so you will not see smooth results you want. This parameter is most often set ONCE to limit feedrates and left alone. There are several other ways to control feedrate WHILE a program is executing... -using the % Command is fine and can be changed at any time while running a program -if you want to get a controlled stop in middle of program execution the best approach is to use the "H" command for Hold - this will bring the motion to a controlled stop, you can leave the % command alone, when you want to start again send the "R" run command and machine will accelerate to the currently set % value of Feedrate. This is similar to the %0 command but not the same. -There are other commands and methods to do what you ask, but the "H" command is most often used. -Look in the Turbo Software Reference Manual Page 352 under the "H" Feedhold command for more details and references to other commands that do similar. Let us know if this works for you or need more clarification. [/quote]

The system I have inherited uses a % Feedrate control based on the I10 and M5198 variables (only CS1 used). As I understand it if M5198=I10 then we have 100% feedrate, for 10% feedrate we set M5198 to I10/10 etc. This works reasonably well but very occasionally M5198 appears to change by itself! This becomes a real problem when trying to stop the machine in a controlled manner, the previous application engineer decided that to do this he would call a PLC, this PLC calls a "&1 %0" command and then sits and waits for M5198 to reach 0. this can take 1-3 seconds but sometimes takes a minute or more - monitoring M5198 in the watch window shows it counting down towards zero before rising then counting down again - eventually it gets to zero but as this is my machine controlled stop PLC the machine may have trundled off the end of its rails by then!! Are there any system functions that change this variable? Has anyone else had experience of this? Thanks

[quote='Unit101' pid='568' dateline='1280146729'] What Programming enviroment are you using ? You should be able to look thru the code and see what is going on I went to extra effort to comment it thouroughly. Feel free to email or give me a call to discuss, a 5 min phone call I can more completely explain what I have seen, tested and worked on. [/quote] I'm using VC++6 at the moment, this problem is an issue with software that has been around for 5-6 years already and this problem has only just come to light. At the moment I'm working on another project so I will only get to work on this in my spare time (whatever tht is!) or if it happens again, I've also got holidays coming up next week. I'll read through what you've sent and next time I get chance I'll get in touch to work it through. Once again thanks for the support

Unit101, thanks for that - glad to know I'm not the only one looking at this problem! I don't have VS2010 C# or any way of compiling your example but I'll have a look through it and see if I can't figure out what you have done, I'll email you directly with more questions if thats OK... Cheers!

[quote='Sina' pid='558' dateline='1279922925'] [i]"When you plug a PMAC through USB to a Windows PC, the Windows device manage will detect the PMAC as PMAC USB0 and the PCommServer will talk to it, lets say as device0. When the USB connection drops for a split second, may be gets disconnected and connected again, device manage detects it again, but since the previous device (PMAC USB0) is still not dropped from the list of devices conncetd (device manager hasn't timed out on that unit yet), it will install the device as PMAC USB1 which is different than what PCommServer knows as device0. You can double check this by looking up under unregistered PMAC devices accessible through Setup menu of PEWIN32PRO2."[/i] [i]The correct fix is to figure out why the USB connection is dropping. However you can patch it by adding a timeout functionality to your software.[/i] [/quote] Yeah I can see how that might happen. The USB is dropping because I have a dodgy cable which is easy to fix - I've just fitted a new cable. What I want to avoid is an unsafe situation, for I example I command the machine to start moving then it hangs before I can issue a 'stop moving' command. If a timeout at my end is the only way to do it then thats what I'll have to do!! Thanks for your help.

[quote='steve.milici' pid='549' dateline='1279825974'] The hang-up could be the PcommServer. Try briefly removing the USB cable and then use the Windows Task Manager to manually end the PcommServer process. This should keep you from having to re-boot the computer. A power cycle to the UMAC may also be required. [/quote] I already figured out that if you switch the USB connection on the PC to a different slot it 'resets' itself and all is ok again but this is a fix not a solution, I can't ask the customer to restart his machine every time PCommServer hangs! Does PCommServer not have some sort of watchdog function that can be monitored? Or do I have to set up a timeout timer at my end and if I do how do I restart everything programatically?

Our systems use either a brick or clipper via the USB connection and send commands with the PmacGetResponseEx() command. Recently I had a problem with a bad USB cable which caused my software to hang, on restarting the software I had no comms (or at least appeared to have no comms) with the brick/clipper. Rebooting the controlling PC cured the problem until the next USB glitch. I've replicated this problem on the bench by briefly disconnecting the USB cable but what I don't see any way of doing is safely getting round this problem - it appears that PmacGetResponseEx() never returns so I have no way of checking the return value for error. Is there any way I can either check that the USB connection is good before issuing the PmacGetResponseEx() command or otherwise returning from it in a controlled manner?