Bag M03

[Demondor]

Good afternoon, Tom. An interesting bug was discovered, I wrote my program on net to control the machine. There is no spindle in our machine, we use a belt sander grinder. To switch on, we used the M code M03 - SetBit. Everything works, but the machine does not turn on 2-5 times a day and the execution of the G code stops. It does not show any errors, polling the current state of the interpreter on request showed ishalt = false and isabort = false. Movements through Move in the console are performed, beats can be put on or off, i.e. kflop is not frozen and works fine. You can get out of the situation by stopping the execution of the program and starting it again, then everything works fine further. If you replace M03 with M103, then everything works great. The glitch is not dangerous, as it has a solution, but it is present. The program is executed 700 - 800 times per day, version 4.34. That's all, thanks.

[TomKerekes]

Hi Demondor,

I'm not aware of anyone else having such an issue. Or a reason M103 would act differently from M3.

If your able to run Visual Studio in Debug mode for your Application the simplest thing would be to break the code and look at what the worker thread is doing or waiting for.

I've also attached a program to pring many of KFLOP's internal variables that may give some clues

[Demondor]

Thanks, Tom. I will try the code you sent me next week, now there is no time. I will unsubscribe by the result.

[Demondor]

Hello Tom. As it turned out, the stop occurs when using other M codes, in addition, we use our program built on your NET library, bugs were found in it and now we are working on improvements and improvements.
This is what your code returned.

Position = 0
StartPosition = 0
LastUpdatePosition = 0
RevsPerCount = 0
UpdateTick = 0
ServoTick = 83169710
DeltaTicks = 0
AdjTimeFilt = 0
LastCSTime = 0
pEncoderPos = 0
K = 0
TrueSpeedRPS = 0
InvBaseSpeedRPS = 0
InvBaseSpeedRPSK1 = 0
InvUpdateTime = 0
Tau = 0
Type = 0
ThreadingActive = 0
CS0_t = 0
CS0_TimeBase = 9e-05
CS0_TimeBaseDelta = 1.905882433129e-08
CS0_TimeExecuted = 0
CS0_t = 0
CoordSystem0 = 0
LastCoordSystem0 = 808ab2f8
LastValidTrajSegment = 0
CS0_StoppingState = 0
CoordSystem0->trajectory_mode = 18
CoordSystem0->t = 0.000000
ch0->Enable = 1
ch1->Enable = 1
ch2->Enable = 1
KLP = 0.000000
DoingEndMotion = 0
KFLOP 4.34 Build 16:07:06 Aug 14 2018

I think it's worth checking after all the changes and fixes in our program.
P.S. For the exhibition, we made a program for translating photos into G code, that's what happened.
https://www.youtube.com/watch?v=mji-0JznuoA

[TomKerekes]

Hi Demonder,

It isn't clear if you stil have the problem after your bug fixes? When was the printout made?

The printout shows CoordSystem0 = 0 which means no coordinated motion is currently in progress. Any previous Coordinated Motion was halted, aborted, or KFLOP Reset to Its default state.

[Demondor]

Hello Tom. Rewrote my program to use your library, added network control and many other cool things. When everything is ready, I'll shoot a video. Fixed the error. We are processing the product as follows. First, the workpiece is measured, and then the desired program is selected based on the results. The measurement process was carried out in the second KFLOP thread (in the first initialization, and in an infinite loop polling keys, bits and controlling external devices). After everything was brought together in one stream, the stops stopped. Thanks.

[TomKerekes]

Hi Demonder,

Thanks for posting back. Looking forward to the video.