A problem with outputs

If you have a question about the software please ask it here.

Re: A problem with outputs

Postby cncdrive » Sun Oct 14, 2018 6:06 pm

Maybe you thought about passing motion g-code line with exec.Code?!
That will pass the command to the motion buffer and then the exec.Code will finish.
That still does not mean that the lines don't run in linear order, they do, but the exec.Code finishes as soon as the command is passed to the controller.
The programmer then can decide if he wants to wait for the motion to stop using e.g. a while ismoving loop or if he wants to do other things while the motion is ongoing.
If the exec.Code would wait for the motion to end that would limit what the programmer can do.
But I think we have talked about this several times, that it is impossible to decide what to allow the programmers to do, I mean if we allow too many things then that is a problem for some people and if we allow too few things then that is a problem for other people.
For Terry it seems that both is a problem. :)
I mean in some cases Terry told me to allow more and now this "linear order of lines issue" suggests to allow less.
So, what should we do?! :)
cncdrive
Site Admin
 
Posts: 2301
Joined: Tue Aug 12, 2014 11:17 pm

Re: A problem with outputs

Postby Vmax549 » Sun Oct 14, 2018 8:36 pm

Balazs can you give an example of HOW this would limit macro programs if everything ran in perfect order ??

WHY would I need to do 2 things at the exact same time in a macro?? I am not sure CNC requires that.

Are you talking about macro Wizards and #events ??

Yes we have talked about it before but I never got a real example of execatly what it would effect. NOW would be a good time to fully explain it.

I am not talking about macros that are mainly for motion control like a complex probing macro. I have a useable solution for Macros with Gcode MOTION. I mainly use exec.CodeSync() and I have a different way of programing it that is much simpler( less coding) . Also there are some "hidden" features of CodeSync() I discovered that can be very handy .

I am talking about something like a complex tool changer macro that relies on precise code control. With over 2000 lines of code a full 25% of that was declaring waits of various manors trying to keep the code sync under control.

Also this is just a discussion and I am not asking for you to change anything. I explained to you LONG ago that I will make suggestions based on experience and that I am not demanding anything be changed. YES I will argue a point about a feature or function I suggest. WHAT would be the point of a discussion if there were never any point counterpoint involved?? And yes I may asked teh same question several times over time to see IF the answer changes and SOMETIME it does.

Now if that offends you or anyone else please say so and I will take care of that problem .

Just a thought, (;-) TP
Vmax549
 
Posts: 1380
Joined: Sun Nov 22, 2015 3:25 am
Location: USA

Re: A problem with outputs

Postby beefy » Sun Oct 14, 2018 8:40 pm

Vmax549 wrote:My Question and concern is WHY Macros cannot be made to just run in linear order. Complete each line of code before starting teh next. That would eliminate any need for Wait()/Sleep() by the users. I am constantly having to GUESS how long to wait to make SURE it completes but not wanting to add more than is needed as that time can add up over Long routines. IF i fine tune it for this PC then the next PC it may have to be tweaked to another value.

(;-) TP


Terry,

like Balazs, I'm a little confused by what you mean. In most programs, each line of code completes before moving onto the next.

As for macros running in linear order, do you mean macro 1 runs and completes, THEN macro 2 runs and completes, and so forth. If that's what you mean, one idea off the top of my head is flags. You could even create LEDs (one for each macro) which are set at the end of each macro. So all macros are actually running at the same time but they're all "scanning" for the LED of interest to come on.

So macro 2 is waiting for the "macro 1 finished LED" to come on. When it comes on, macro 2 immediately turns it off then runs its code. This way you could have heaps of macros running yet they ALL can run sequentially.

Or was that not what you meant at all :lol:

Keith
beefy
 
Posts: 198
Joined: Mon Sep 05, 2016 10:34 am

Re: A problem with outputs

Postby Vmax549 » Sun Oct 14, 2018 9:39 pm

HI Keith I am talking about lines of code inside of a macro running in perfect sync without teh use of wait states.

And I have found that without the use of wait() things to do NOT always run in perfect order. For example

AS3.Setfield(1.111,100);
exec.Wait(100);
AS3.Validatefield(100);
exec.Wait(100);
exec.Code("G0 X"+AS3.Getfield(100));
while(Ismoving()){;}

Without the Wait() after setting teh DRO or validating there is a chance that teh DRO will NOT get set or validated before it is called into use. IF it ran in perfect order I would never need to use a wait to control code flow. Out of 6 lines of code 3 were needed JUST to control the flow of the code.

AS3.Setfield(1.111,100);
AS3.Validatefield(100);
exec.Code("G0 X"+AS3.Getfield(100));

At least that is what I see HERE. Let me KNOW if you GUYS have never seen teh problem on your end.

(;-) TP
Vmax549
 
Posts: 1380
Joined: Sun Nov 22, 2015 3:25 am
Location: USA

Re: A problem with outputs

Postby ger21 » Sun Oct 14, 2018 9:57 pm

Is the wait in this case required to wait for the screen to be updated?

If you wrote 1.111 to a var, then read it, would it still require the wait? I don't think so.

I've always used wait when writing to fields, just out of habit, as Mach3 required them to allow for the screen to update.
Gerry
UCCNC 2017 Screenset - http://www.thecncwoodworker.com/2017.html
ger21
 
Posts: 1155
Joined: Sat Sep 03, 2016 2:17 am

Re: A problem with outputs

Postby Dan911 » Sun Oct 14, 2018 11:15 pm

Each line will complete, the wait's aren't needed.
Dan911
 
Posts: 470
Joined: Mon Oct 31, 2016 1:22 am
Location: USA

Re: A problem with outputs

Postby cncdrive » Mon Oct 15, 2018 3:25 am

Balazs can you give an example of HOW this would limit macro programs if everything ran in perfect order ??


Terry, I can't give a concretised example, but I can describe it to you.
A motion command can take long time to finish and the programmer/user might want to do things, check things, execute some other non motion things while the motion is still ongoing.
If the exec.Code would give the control back to the macro only when the command, the motion would fully finish then the programmer/user could not do anything else in the meatime.
In my opinion this would limit the programmer if they will have no other choice than to wait and could not run any other codes and tasks.
And again, ofcourse the lines execute always in the correct order, it is handled by the .NET C# compiler (CodeDOM) which ofcourse does not execute code in a random manner...
A time wait in those cases are not needed, but a wait with ismoving check can be done to wait the exact time until the motion is finished.

I'm not offended at all, I'm just trying to point out that there is a contradiction, because on one hand you often ask for more freedom in what can be done and one the other hand you want something which would give less freedom...
cncdrive
Site Admin
 
Posts: 2301
Joined: Tue Aug 12, 2014 11:17 pm

Re: A problem with outputs

Postby Vmax549 » Mon Oct 15, 2018 4:22 am

Hi Balazs, It is interesting that you say it cannot get out of sync but I see that it does and by applying the waits corrects that problem so something is amiss on my end. I can think of NO situation in CNC where I would want to do as you suggested having teh controller do something else while it is completing teh motion block. If someone can give me a valid example maybe I could understand the point in being able to do that.

In testing I use 4 PCs that run 4 different OS using 3 controllers and 1 in sim mode(demo)

4 pc different Manf and configs
4 OS W2kpro, XPpro,Vista,Win7 all 32 bit mode
3 controllers uc400eth UC300 UC300eth

And I have seen it in ALL Controller situations and PCs including teh Demo mode and it is the hardest to track results over time.

Motion is a 3 axis plotter that plots teh pattern produced by teh Code. That way I can SEE diviations in teh plots IF it gets out of wack as the pattern will change. It plots on a 30" sheet of paper and can do a half Zillion plots per sheet on both side of the paper. Old school testing and recording (;-). On teh Demo(sim) mode I can only track total motion distance per axis. Over time iF teh pattern diviates then teh total distance traveled diviates as well.

Gcode only testing runs perfect over time. Macros not so much. Probing over time will show trip point errors. You related it to a poor ethernet (slow) connection. I used 2 senarios onboard ethernet and a high end PCI card both would show errors over time probing.

In real world testing I simple watch what problems Derek may come across over time. He has cut countless program cycles over time adn countless tool changes from his 2 ATCs and is an EXCELLANT test bed for dependability and problems. AS he simply repeats the same process many times over time and if anything odd show up it is EASY for him to pick up on it happening.

But if you say it should never happen then I am doing something seriously wrong in UCCNC and I need to stop working with UCCNC until I can figure out what that problem is.

See you in the funny papers, (;-)TP
Vmax549
 
Posts: 1380
Joined: Sun Nov 22, 2015 3:25 am
Location: USA

Re: A problem with outputs

Postby Vmax549 » Mon Oct 15, 2018 1:16 pm

Hi Ger,

" If you wrote 1.111 to a var, then read it, would it still require the wait? I don't think so. "

I would not bet your lunch money on that . IF you really believe that then STOP using Wait() in your Macro code. Better yet remove all waits from your existing macros and Then track your customers using them over time. ;)

I started out believing that as well and I KNOW what happens. Customers will start complaining about random glitches with macros. Put those waits back in and presto problem solved everyone happy again.

The normal pattern will be everything works for days then all of a sudden it starts glitching. When that starts it will repeat many times UNTIL you restart UCCNC. Then it goes back to normal until it starts again.

Been there done that ;) BUT that is just my experience, Your mileage may vary due to local conditions

(;-) TP
Vmax549
 
Posts: 1380
Joined: Sun Nov 22, 2015 3:25 am
Location: USA

Previous

Return to Ask a question from support here

Who is online

Users browsing this forum: No registered users and 4 guests