[mmurray70]

Hi Tom,

Wondering if theres a way to view the console directly from Kmotioncnc? Maybe add a small console to the main screen with screen editor? Or a button to open a new window without having to open kmotion? I sort of recall someone asking something similar before but cant find it now.

I configured m30 to print true cycle time (including part change) and check this fairly often. Would be nice if i could display it on screen or have it one click away. Thanks.

Mark

[TomKerekes]

Hi Mark,

Noted. You might use the Screen Editor to add a DROLabel on the Screen then have the M30 write the cycle time there.

Regards

[mmurray70]

Hi Tom,

Im going to try and add a DRO label as you suggest, and another to show feed per rev. But im having some trouble getting anything to display.

I just added the "Screen Value to Jog speed" feature and this is working well. I added to the code of this program to try and print to another dro but cant get it to display anything. What am I doing wrong. See attached screenshot for DRO settings and code below:

#include "KMotionDef.h"

#define TMP 10 // which spare persists to use to transfer data
#include "KflopToKMotionCNCFunctions.c"

#define MAX_JOG_SPEED_X 210.0 // ipm
#define MAX_JOG_SPEED_Y 210.0 // ipm
#define MAX_JOG_SPEED_Z 210.0 // ipm

void UpdateJogSpeeds(void);
void DoLimitJog(double rate, int cmd);


main()
{

	double IPR;
	char s[80];

	for (;;)  // forever loop
	{

		// set jog rate
		UpdateJogSpeeds();
		Delay_sec(0.005);
		// end set jog rate


		//Display Feed Per Rev
		IPR = 0.0123; // random feed to test display
		sprintf(s,"Feed = %8.2f ipr\n",IPR);
		DROLabel(1000, 151,s);
	}
}

//set Rate within Limits
void DoLimitJog(double rate, int cmd)
{	
	rate = rate * 2;
	if (rate < 0.0) rate=0.0;
	if (rate > 1.0) rate=1.0;
	
	DoPCFloat(cmd, rate);
}

void UpdateJogSpeeds(void)
{
	static LastChangeCount=-1;
	int Units, TWORD, HWORD, DWORD;
	double rate;
	
	// don't bother if nothing changed
	if (EditChangeCount == LastChangeCount) return;

	// remember count before updating
	LastChangeCount = EditChangeCount;
	
	// Read double from a KMotionCNC Edit Control
	// Persist Var identifies the Control and contents specifies 
	// where the string data should be placed in the 
	// Gather Buffer as an offset in words
	if (GetEditControlDouble(&rate, 150, 1000)) return;  // exit if value is invalid
	
	GetMiscSettings(&Units, &TWORD, &HWORD, &DWORD); // check Units
	if (Units == CANON_UNITS_MM) rate = rate/25.4; // convert screen value to ipm	
	DoLimitJog(rate/MAX_JOG_SPEED_X, PC_COMM_SET_JOG_OVERRIDE_X);
	DoLimitJog(rate/MAX_JOG_SPEED_Y, PC_COMM_SET_JOG_OVERRIDE_Y);
	DoLimitJog(rate/MAX_JOG_SPEED_Z, PC_COMM_SET_JOG_OVERRIDE_Z);
	
}

[TomKerekes]

Hi Mark,

I think you have the hide "hide" property set for the "IPR" DROLabel control. When a control is shown in yellow it indicates hidden, yet selected.

To make a control visible:

#1 select it (you may need to select "Show Hidden")
#2 press "show"

Otherwise your code seems to work for me.

Attachment 401210

On a minor note you shouldn't need the new line character \n in the label characters so you might remove it.

If you still have an issue post the screen script (as a txt file) so we can check it.

Regards

[mmurray70]

Ok yes that would certainly explain it. Sorry, not sure how i missed that lol.

I have it sort of working now. Im using variable 151 to show feed per rev, and 152 to show cycle time on another DRO. But that program is printing feedrate to both dros?? And If i kill that thread m30 prints cycle time fine to the second dro with var 152 which is very strange. I did double check the numbers are right in the screen editor but i must be missing something, ill look it over again tomorrow.

One more thing, i'm guessing that its better to leave this code in a separate thread with a slight delay in the loop instead of putting it in my init right?

[bhurts]

I don't know if this is taking things off topic so I apologize ahead of time just in case. I am wondering if it would be possible to show the axis screen load graph as well as the analog I/O screen adc's, supply, and temperature values on the kmotion screen using similar methods. Note these values monitor snapamp in my system.

Thank you
Ben

Sent from my E6810 using Tapatalk

[TomKerekes]

Hi Mark,

I have it sort of working now. Im using variable 151 to show feed per rev, and 152 to show cycle time on another DRO. But that program is printing feedrate to both dros?? And If i kill that thread m30 prints cycle time fine to the second dro with var 152 which is very strange. I did double check the numbers are right in the screen editor but i must be missing something, ill look it over again tomorrow.

Besides using the persist variable to trigger the string to be uploaded, the string must be placed in memory somewhere. That is what the 1000 is in this function call is for:

DROLabel(1000, 151,s);

1000 is an offset into the 8 megabyte gather buffer where the string is to be placed. If you send one string at a time to various DROLables you might be able to use the same memory for the strings. But if updating multiple DRO labels at the same time, separate memory areas must be used. Its probably simplest to always use separate memory spaces. So for example to leave space for strings 100 characters long you might do:

DROLabel(1000, 151,string1);
DROLabel(1100, 152,string2);

One more thing, i'm guessing that its better to leave this code in a separate thread with a slight delay in the loop instead of putting it in my init right?

Good question. I would expect you could use the same Init Thread for setting the DROLabels as long as you use a Timer in order to only do it periodically. The strings are fairly quickly placed in memory for KMotionCNC to upload later, so it shouldn't have a big impact on the loop timing. I measure ~60us to format the string with sprintf and the call to DROLabel takes ~25us.

However when the Operator Types into the Jog Rate control and KFLOP is informed of a change multiple interactions with KMotionCNC is required to request and receive the Rate values and the Units. KMotionCNC only services this on ~100ms intervals so it can take ~500ms for all this to occur.

Its like sending vs getting information to/from a friend via mail. To send you can just drop a note in the mail and you are immediately done (if/when he receives it isn't your issue). To get information you must first mail a request. Then wait days before possibly receiving a response.

The call to GetEditControlDouble(&rate, 150, 1000) currently blocks waiting for the response. We could re-write it in a way where it doesn't block but rather returns whether the response was received or not.

I'm not sure which is simpler: Using two Threads or a non-Blocking approach.

[TomKerekes]

Hi Ben,

I am wondering if it would be possible to show the axis screen load graph as well as the analog I/O screen adc's, supply, and temperature values on the kmotion screen using similar methods. Note these values monitor snapamp in my system.

Yes you should be able to display such status numerically or graphically using the Screen Editor. The Screen Editor has a Vertical Bar (VertBar) control type for simple graphics. Your C Program would set a persist variable as a floating point value fro 0.0 to 1.0 to update the graph. See the example ShowInstantVelocityDROBar.c and ShowInstantFeedRate3AxisBar.scr.

Attachment 401226

Regards

[mmurray70]

Hi Mark,

Besides using the persist variable to trigger the string to be uploaded, the string must be placed in memory somewhere. That is what the 1000 is in this function call is for:

DROLabel(1000, 151,s);

1000 is an offset into the 8 megabyte gather buffer where the string is to be placed. If you send one string at a time to various DROLables you might be able to use the same memory for the strings. But if updating multiple DRO labels at the same time, separate memory areas must be used. Its probably simplest to always use separate memory spaces. So for example to leave space for strings 100 characters long you might do:

DROLabel(1000, 151,string1);
DROLabel(1100, 152,string2);

Good question. I would expect you could use the same Init Thread for setting the DROLabels as long as you use a Timer in order to only do it periodically. The strings are fairly quickly placed in memory for KMotionCNC to upload later, so it shouldn't have a big impact on the loop timing. I measure ~60us to format the string with sprintf and the call to DROLabel takes ~25us.

However when the Operator Types into the Jog Rate control and KFLOP is informed of a change multiple interactions with KMotionCNC is required to request and receive the Rate values and the Units. KMotionCNC only services this on ~100ms intervals so it can take ~500ms for all this to occur.

Its like sending vs getting information to/from a friend via mail. To send you can just drop a note in the mail and you are immediately done (if/when he receives it isn't your issue). To get information you must first mail a request. Then wait days before possibly receiving a response.

The call to GetEditControlDouble(&rate, 150, 1000) currently blocks waiting for the response. We could re-write it in a way where it doesn't block but rather returns whether the response was received or not.

I'm not sure which is simpler: Using two Threads or a non-Blocking approach.

Hi Tom,

You were right, I was using 1000 for both, I changed to 1100 and its working fine now thanks. This is pretty cool to be able to send anything to the screen like that without too much trouble. I think im going to add another to print run time from the start of program, ill set it up with another M code to record start time. Would be nice to see both run time and cycle time.

I guess there are pros and cons of each when it comes to the threads. It would be sort of convenient to have it all running in one thread but I don't think I mind having two in this case. Almost seems to me like its better to have the init running smoothly on its own doing the important stuff and not having anything to do with the PC. And having another thread handling the communication with the PC. I have it setup now with an M code to start this second thread, and thats done automatically anyway when i run init so really no big deal.

Ben, I also considered adding load meters that would be based on DAC values. Would be a nice feature, You would need to average the values for a period of time to get any sense out of them, not sure how much trouble that would be. Im sure Tom would have a way of doing it. The meters would take up a fair bit of space on the screen too.

Thanks again Tom.

Mark

[mmurray70]

Hi Tom,

I have all the DRO's working after, using three in total. Two to display run time and cycle time that gets updated by M30. And another that displays feed per rev that gets updated several times per second (I forget exact number but can check). Everything is working well with the DRO's, but it seems to be slowing down Kmotioncnc. Whenever I try and access the tool and fixture tables now there is a considerable delay before they open, sometimes 8-10 seconds or more. I think the boxes themselves may be grayed out a little longer at program end as well.

Any suggestions on how to speed it up? Is there a way to make kmotioncnc read the variable less often or something? Have you ever noticed any slow down? Is there a chance I have something done wrong thats causing a conflict or something?

[TomKerekes]

Hi Mark,

I wouldn't expect this. I just checked a single DRO updating 100 times/sec and I don't see any such issue.

Can you post your Screen Script and C Program for us to look at?

Regards

[mmurray70]

Hi Tom,

Here are the files.

The delay seems most noticeable after doing something else. Like right after finishing a program or starting and stopping the spindle or something. If its just sitting there idling it isnt as bad. Thanks.

Mark

[TomKerekes]

Hi Mark,

Thanks but unfortunately I'm not able to see any delay with these files or any others I've tried.

One remote possibility is:

IPR = Rate / RPM;

this could be a divide by zero if the Spindle RPM is zero or near zero. That could result in IPR being a 300+ digit number causing the 80 char array buffer to overrun and cause memory corruption. But forcing that didn't seem to do what you see. There should really be a test for near zero ie. if (RPM < 0.01)

Otherwise any other info/clues you could provide on how to duplicate would help. It appears you have some other C Programs to set the Start Cycle time and such that you haven't provided. Also the Tool Setup for Threads, Vars, etc... might be helpful.

You might also delete functionality piece-by-piece to find specifically what triggers the issue. It might even be totally unrelated to the custom screen for that matter.

Regards

[mmurray70]

Hi Tom,

Thanks for the help. As a test i blocked all the calculations with comments and just set IPR equal to 0.010 and its still slow. And on the other hand I tried letting all the calculations run and blocked the DROLabel(1000, 151,s); line and it runs perfect. So seems like this line is causing the trouble. Runs ok with this code:

for (;;)  // forever loop
	{

		// set jog rate
		UpdateJogSpeeds();
		Delay_sec(0.05);
		// end set jog rate


		//Display FPR
		
		t0=WaitNextTimeSlice();
		x0 = ch0->Dest / CNTS_PER_INCH_X;
		y0 = ch1->Dest / CNTS_PER_INCH_Y;
		z0 = ch2->Dest / CNTS_PER_INCH_Z;
		t1=WaitNextTimeSlice();
		dx = ch0->Dest / CNTS_PER_INCH_X - x0;
		dy = ch1->Dest / CNTS_PER_INCH_Y - y0;
		dz = ch2->Dest / CNTS_PER_INCH_Z - z0;
		
		d = sqrt(dx*dx + dy*dy + dz*dz);

		Rate = d/(t1-t0)*60.0;
		
		float RPM = *(float *)&persist.UserData[9]; // s value from g code

		
		IPR = Rate / RPM;
		if (!ReadBit (154) && !ReadBit (155)) IPR = 0;

		sprintf(s,"Feed = %1.3f ipr\n",IPR);
		//DROLabel(1000, 151,s);
	}

Let me know if you have any more suggestions. Also you said 1000 refers the portion of memory used to handle this, would it be worth trying a different number? Thanks again.

Mark

[TomKerekes]

Hi Mark,

Well that confirms sending the data is the issue as expected. But no clue why you have an issue and I don't.

When KMotionCNC reads the persist 151 as non zero indicating a new string to display it reads a fixed block of 200 characters from the gather buffer. The 200 characters are read as hex values so each character takes about 2 bytes through the USB. So it involves about 400 bytes of USB traffic.

The example program SimpleFormsCS.exe has a button to test USB Speed. I have a fairly fast computer and get:
KFLOP->PC N=100000 Int32, Time=1.971 sec, 450KBytes/sec

So 400 bytes should take < 1ms, so should only use ~ 1% of the USB bandwidth (KMotionCNC only checks for messages to upload every 100ms regardless of how often you set them to upload in KFLOP).

Please run the test on your computer and see what you get.

Do you have a USB Isolator or anything between KFLOP and your Computer?

Regards

[mmurray70]

Hi Mark,

Well that confirms sending the data is the issue as expected. But no clue why you have an issue and I don't.

When KMotionCNC reads the persist 151 as non zero indicating a new string to display it reads a fixed block of 200 characters from the gather buffer. The 200 characters are read as hex values so each character takes about 2 bytes through the USB. So it involves about 400 bytes of USB traffic.

The example program SimpleFormsCS.exe has a button to test USB Speed. I have a fairly fast computer and get:
KFLOP->PC N=100000 Int32, Time=1.971 sec, 450KBytes/sec

So 400 bytes should take < 1ms, so should only use ~ 1% of the USB bandwidth (KMotionCNC only checks for messages to upload every 100ms regardless of how often you set them to upload in KFLOP).

Please run the test on your computer and see what you get.

Do you have a USB Isolator or anything between KFLOP and your Computer?

Regards

Hi Tom,

Im ran the test and here are the results. Older computer with windows 7. Seems pretty good. The PC to kflop times are much slower. Is that ok? Also you mention kmotion reads a fixed block of 200 characters from the gather buffer. Should we be spacing out the offset in the C program by 200 as well? I used 1000,1100 and 1200 I think.

So just to be sure were on the same page, the actual DRO was updating fine. Displaying IPR and updating very fast. Trouble im having is a delay when hitting the button to open tool offsets and fixture offsets. Thanks again.

Mark

[TomKerekes]

Hi Mark,

The PC to kflop times are much slower. Is that ok?

That seems slow. I've never seen any computer have rates < 300KB/s.

I think I had things running I wasn't aware of before. Now with nothing except SimpleFormsCS.exe I'm getting

PC->KFLOP N=100000 Int32, Time=1.670 sec, 531KBytes/sec
KFLOP->PC N=100000 Int32, Time=1.057 sec, 840KBytes/sec

Note that this USB test uses the Gather buffer from 0-400000 so it causes KMotionCNC to get all manner of errors if the DROLabels are using that range.

Also you mention kmotion reads a fixed block of 200 characters from the gather buffer. Should we be spacing out the offset in the C program by 200 as well? I used 1000,1100 and 1200 I think.

That shouldn't matter as long as the Label messages are less than 100 characters long. It just means the next message is uploaded to KMotionCNC (and not used) instead of extra empty/junk data after the real message.

Sorry I can't duplicate it or imagine what it might be. To bring up the Dialogs doesn't require any communication. It only reads a disk file and displays a dialog. I don't believe the Offset Screen even needs to read a disk file (the offsets are in memory). But adding the DRO traffic somehow causes it. Bizarre. It seems KMotionCNC is stalled/busy waiting for something. I would expect every GUI operation to be delayed not just those dialogs.

You might try removing and updating the KFLOP USB Driver to the one in V4.34

Would it be possible to try a different computer?

Are you able to compile and debug KMotionCNC? If so if you can cause the delay and quickly hit "break all" in Visual Studio KMotionCNC would likely be in a tight loop doing something or waiting on something. What it was doing would be a big clue.

Sorry for no simple answer.

Regards

[m_c]

Could it be the USB port on the computer is going via a couple internal hubs, which happen to be handling something else causing bandwidth latency/speed issues?

Another port may avoid the problem.
I can't remember exactly where, but in device manager it is possible to get a hierarchy view, so you can see how many hubs any given device is actually passing through.

[TomKerekes]

Hi Mark,

I wouldn't expect a hub to be a problem unless the other USB devices have extreme traffic. My tests were performed through a hub.

Microsoft has a tool called USB Device Viewer. Here is a View on my system:

Attachment 403056

My system already had it as I installed the SDK at some point. Here is Microsoft info:
https://docs.microsoft.com/en-us/win...to-get-usbview

Regards

[mmurray70]

Hi Mark,

That seems slow. I've never seen any computer have rates < 300KB/s.

I think I had things running I wasn't aware of before. Now with nothing except SimpleFormsCS.exe I'm getting

PC->KFLOP N=100000 Int32, Time=1.670 sec, 531KBytes/sec
KFLOP->PC N=100000 Int32, Time=1.057 sec, 840KBytes/sec

Note that this USB test uses the Gather buffer from 0-400000 so it causes KMotionCNC to get all manner of errors if the DROLabels are using that range.

That shouldn't matter as long as the Label messages are less than 100 characters long. It just means the next message is uploaded to KMotionCNC (and not used) instead of extra empty/junk data after the real message.

Sorry I can't duplicate it or imagine what it might be. To bring up the Dialogs doesn't require any communication. It only reads a disk file and displays a dialog. I don't believe the Offset Screen even needs to read a disk file (the offsets are in memory). But adding the DRO traffic somehow causes it. Bizarre. It seems KMotionCNC is stalled/busy waiting for something. I would expect every GUI operation to be delayed not just those dialogs.

You might try removing and updating the KFLOP USB Driver to the one in V4.34

Would it be possible to try a different computer?

Are you able to compile and debug KMotionCNC? If so if you can cause the delay and quickly hit "break all" in Visual Studio KMotionCNC would likely be in a tight loop doing something or waiting on something. What it was doing would be a big clue.

Sorry for no simple answer.

Regards

Hi Tom,

I appreciate the help but I think I might just let this one go. I really dont need IPR display, it was sort of nice on the Mazak I used to run at my old job, but as I said I really dont need it. Sounds like it could be a lot of work to get this going and I dont really have the time right now to invest for something so simple. Im not sure how to compile and debug Kmotioncnc. I dont have any programming experience or knowledge other then the little bit of C programming that I learned just to use with kflop.

I don't have an extra computer to try right now but I was planning on setting up another one as a backup just in case this one causes trouble. If I ever get around to that ill try it again and see if theres any difference. But for now I think ill just live with out feed per rev display. Thanks again for all the help.

Mark