Sleep Command

[howling60]

the sleep command within camsoft, is this only providing a "pause" for the current macro/mcode/etc that is running, or does it pause all execution of commands (such as watching the inputs changing state). the command listing in the manual does not seem to really have any explaination.

i ask this, because as i continue to get my tool changer to run correctly, the tool pot counting routine runs just fine, as long as i don't have the tool changer arm currently changing tools. As soon as i have the added I/O running for the changer arm, the counting routine seems to often "miss" pots as they go by the switch. I don't think this is within my inputio logic, as it all runs quite happily when there are not multiple processes trucking along.

thanks for the info!

-nate

[camsoft]

Good Morning Howling60

If you have two or more things at once happening it would be best to use the IF THEN GOTO commands rather than SLEEP because it will slow down other routines and have an affect on other timing sensitive logic as well as the WAITUNTIL command does also. Both with keep the system busy but the IF THEN commands together with GOTO in a tight loop will allow the processor to give up time in between to other logic more freely.

' Alternative to SLEEP
' This routine resets the time counter and waits for
' a certain number of milliseconds to elapse to continue
' 1000 ms equals 1 second
'
TIME RESETMS
:LOOP
TIME MS;\55
IF \55<1000 THEN GOTO :LOOP



' Alternative to WAITUNTIL
' Example routine thats waits for Input #16 to turn off
'
:LOOP
IF #16<>0 THEN GOTO :LOOP


Tech Support
CamSoft Corp.
951-674-8100
support@camsoftcorp.com

[howling60]

that's what i was afraid you were going to say.. well.. off to re-write all kindsa logic.. booo...

thanks

[howling60]

Originally Posted by camsoft ' Alternative to WAITUNTIL ' Example routine thats waits for Input #16 to turn off ' :LOOP IF #16<>0 THEN GOTO :LOOP

so, i have a possibly dumb question, but i believe i had this sort of logic in my code "way back when".. and found that using an MDI, if the m-code, or macro that was called, had any sort of a logic loop such as this, the control was essentially hung. the advice you gave me then was to use a waituntil command, which is what now causes problems, as other io cannot be reliably trapped. i'm very confused now...

i'm going to try the alternative for sleep, and see if that works out any better, as logic loops are still hanging the control.

will update as i make progress.

-nate

[howling60]

so, i just put the "alternative sleep" into my routine, unfortunately, the logic loop within it does the exact same thing as any other logic loop for me, it hangs the MDI window and won't allow the routine to run.

I tried to capture this in a log file, but even the M6 call isn't captured in the log file, let alone the logic that is attempting to run.

I'm not trying to be mean, or start a flame war, but am asking an honest question.. does anyone else have a machine that is using a tool chain running independantly in the background, while the changer arm is off actually changing the tool? If so.. care to shed some light on how this was accomplished, as i am just about at my wits end. I suppose i *could* redo the routines, so that the tool chain will only operate while nothing else is happening.. but this is not really acceptable to me & those who will be running the machine.

thank you for any insight/light you can shed on these issues.
If my cbk file would be of any use, i can send it along if need be.

-nate

[camsoft]

Howling60,

It is hard to comment correctly without knowing more and seeing the files and also even speaking with you to ask questions.

It's very possible that some one could help you posting here and if you were merely curious we would understand your previous reason for posting here but since it now seems important we are offering to investigate. Yes, we would like your latest CBK, History, Job file, Last version installed and notes or some one to speak with to point out where to look. You're under maintenance so it doesn't cost anything for direct support. Having all the info and a live person on the phone makes our job easier and raised the quality of support.

To give you some insight for what we know at this point:

There's no reason why M6 shouldn't show up in the history file. There something else coming into play that's hanging or slowing the system down to a crawl.

The "IF THEN GOTO, SLEEP or WAITUNTIL" commands are designed to wait. To you waiting seems like hanging. However, that is what these are suppose to do to ensure proper program flow. If these commands appear in a M code or Macro within a G code program or are run from the MDI window it would make no difference. It should never hang the MDI screen, but it may be stuck in a loop essentially waiting forever for an event that doesn't happen so it appears to be hung. For example from MDI or a G code program you write custom logic in an M code or even call a macro from the M code, think of this as a extension of the G code program being ran. Much like a sub routine in a G code program that gets stuck in a repetitive loop and can't break free.


We do need to know the whole situation to comment correctly. While there are limits to the type of I/O (Galil, Ethernet or Auxiliary I/O), CPU index speed, Operating system and complexity of logic and logic commands used we would say ,Yes it should be possible to do both things at once. Is there someone doing the same thing you are? is hard to say. We don't keep those kinds of records and the others that work in this office can't think of any. We will let you know waht is possible once we know what we have to work with.

Tech Support
CamSoft Corp.
(951) 674-8100
support@camsoftcorp.com
www.cnccontrols.com

[howling60]

So, just to make sure i wasn't shooting off without basis, i just wrote an m-code to fire a solenoid, and wait until the corresponding switch was tripped. this movement physically takes about 1.5 seconds to complete.

code was as such

#68=1: #67=0 (fire the solenoid)
:WAIT
IF #52=0 THEN GOTO :WAIT
MESSAGE CHANGER MOVED
---M15

this works fine... when i stepped it up a notch, and put that code, into the macro [ARMSWING] (cut and paste)

i then had

[ARMSWING]
--- M15

when i used the mdi and called M15, the MDI window "hung" as i have taken to calling it. this event is not capturable in a logfile, as the mdi window never is able to complete the m-code (and subsequent macro) call.

I am going to go through and re-code this tool changer, using the if then goto loops, and not using macros, to see if this problem can't be simplified. i still do find it odd that a macro call with a loop internally will cause this to crop up though. If someone else would like to verify this on their control (and make sure it is/isn't just something i have going in the background, it would be much appreciated.)

-nate

[howling60]

Originally Posted by camsoft ,Yes it should be possible to do both things at once. Is there someone doing the same thing you are? is hard to say. We don't keep those kinds of records and the others that work in this office can't think of any. We will let you know waht is possible once we know what we have to work with.

regarding that, it was more of an open-ended question, directed at all the users/readers of this forum. Since there is such a broad user-base out there, i thought there might be someone that had attempted/completed a similar build, and might have some personal experiences/ideas/etc that might be applicable. I wasn't trying to imply that you guys would keep records on what your customers have applied your product to. There are so many different possible applications that the records just wouldn't be feasable to hold onto!

and now, off to try and uncomplicate things on this machine!

-nate

[camsoft]

Hello Howling60 ,

We don't want you to drive you self crazy and waste more of your time, so the short answer is that this logic running in an M code or Macro will hang a G code program or MDI for sure, until #52=0 is not zero.

We are saying the same thing you are. This is true.

The M code or Macro is an extension of the program running as a sub routine would be. The running program will execute up to the M15 then call the macro and wait. It will hold up the program until #52=1. The program will continue once #52 becomes 1.

Tech Support
CamSoft Corp.
(951) 674-8100
support@camsoftcorp.com
www.cnccontrols.com

[howling60]

Originally Posted by camsoft Hello Howling60 , We don't want you to drive you self crazy and waste more of your time, so the short answer is that this logic running in an M code or Macro will hang a G code program or MDI for sure, until #52=0 is not zero. We are saying the same thing you are. This is true. The M code or Macro is an extension of the program running as a sub routine would be. The running program will execute up to the M15 then call the macro and wait. It will hold up the program until #52=1. The program will continue once #52 becomes 1. Tech Support CamSoft Corp. (951) 674-8100 support@camsoftcorp.com www.cnccontrols.com

this makes perfect sense to me (that everything would hang until #52=1)... what puzzles me is that the program seems to ignore the command to energize the outputs prior to dropping into the wait loop. If the solenoid were getting a signal, then input #52 would by default be forced into an on state, dropping out of the loop, as the cylinder would have physically run it over eventually.

i'll go play s'more... if nothing else, i'm becoming familiar enough with the control software that i'm almost seeing it in my sleep!

either way, i'm glad we're on the same page, thanks for the confirmations

-nate

[HuFlungDung]

Nate, looking at your sample:
#68=1: #67=0 (fire the solenoid)
:WAIT
IF #52=0 THEN GOTO :WAIT
MESSAGE CHANGER MOVED
---M15

It is difficult to know if you have covered every contingency. Remember, computers are dumb!

What logic will happen if the switch 52 is made already? Not only do you have to plan for what you want to happen, but you may need to lay out a plan for the alternate branch of the results of the IF comparison.

[howling60]

in this case, the test setup was incapable of having the switch (input #52) in a on state, as it was on the end of a 1.5 foot stroke for a hydraulic ram that is actuated by solenoids on outputs #68 and 67. in all my other logic, i have been covering the "what if it wakes up in X state" possibilities.

and computers ARE dumb.. i keep telling mine to go and make me a sandwich, cause i'm hungry.. it won't do it .. darn computers!



-nate