Hello Guest it is April 27, 2024, 03:45:14 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - jarekk

Pages: « 1 2 3 4 5 6 »
21
Well, I decided to release it like that. But still - there was not much interest, so the project ended up in a drawer collecting dust :-(

But I hope it helped others to understand motion control plugins.

23
Hi,

Some time ago I have started topic about sharing knowledge about motion controllers : http://www.machsupport.com/forum/index.php/topic,17612.0.html
Few monts passed, nobody joined. Since then I have converted virtual idea to real motion  controller.




I spent quite some time on it, copied code from my other projects and got it working. Originally I wanted to share only hardware design and sell licenses for plugin, but after long discussion with Scott “Poppa Bear” I decided to go different way.
I decided to share most of the code ( while keeping all my copyrights) under special license:
-  If you use my device and you are happy with it - please pay 35$  ( in EU 35$ + VAT) to my paypal account. You will find link in the code and in the configuration web page for the device
-  If you want development license ( to reuse my code for your professional product) - it is also possible, see license code for details. In such case you will get full source code plus free consultancy to get most from it.
-  If you just want to examine the code - feel free to do it.  The Mach SDK is poorly documented and the examples are messy, so it may help you with your Mach development.

About the device itself:
- 4 axis support
- 100 kHz step/dir frequency
- LPT DB25 connector (as it emulates PC parallel port)
- Easy to assemble hardware design ( main components are DIP, all passives are SMD – 1206
or bigger, possible to make on single layer PCB)
The ethernet connection provides following features:
- Web interface for configuration
- DHCP client/server support
- NetBIOS support ( for accessing device by its name)
Known limitations:
- No slaving support ( not yet implemented)
- No threading support for lathes ( not yet implemented)
- No spindle support ( not yet implemented)

It still requires a lot of testing ( I am preparing few units for my friends for serious testing in real production environment). I have successfully run it on my simple gcode, homeing, jogging but  I am sure there will be issues on some specific configurations. Especially that motion plugins are left alone for jogging and homeing ( so I had to implement it myself) and I am not sure that it is 100% compatible with e.g. LPT operation.  Please let me know if you find something - I will fix it.

I will always post latest code and documention in finished plugins section: http://www.machsupport.com/forum/index.php/topic,19698.0.html


24
finalizeMoves() is called when Mach finishes your Gcode processing - so it is correct behaviour.

About:  ExternalPulseRates, motor velocity, ExBufferHi and ExTime - these are configuration variables for your plugin. All these settings are independent. Most were described in my plugin.
 ExternalPulseRates - your max step signal frequency
 ExBufferHi - max lookahead buffer for movements
 ExTime - tyime slice for single motion record ( time period with constant speed data records you get from trajectory)
 motor velocity - this describes CNC machine movement constrains

25
About th M3 stop - Well, I do not understand what you really mean.


About the position update - have you analyzed my code at all ? :P

It is your responsiibility to update Mach variables  - it is your plugin which is supposed to create motion according to given trajectory and report back the result ( as position).

Once uoy update position, you will also get tool view updated.

26
//
 void MyDeviceClass::Dwell(double time)
 {

   // Calculate dwell time and record timestamp - will be serviced from state machine
   if( !MainPlanner->DwellMilli )
   {
      time = time * 1000;
   }
   
   DwellTimestamp  = GetTickCount();
   DwellDelay      = (DWORD)time;

   // Tell Mach we are dwelling
   Engine->DwellTime = 1;

   // There is silent assumption that dwell request will  come
   // only during GCode execution, when there is no other sequences running
   // ( no homing,jogging probing - etc.)
   assert( (sequence == SEQ_IDLE) || (sequence == SEQ_DWELLING) );

   sequence = SEQ_DWELLING;


   stats.DwellCall++;
 }

27
Dwelling tells your plugin to stop processing ( and executing) movement as e.g. spindle needs some time to reach its operational speeds ( may take few seconds). That is why you have noticed it after M3 ( it enables spindle ). But this is only one of few possible cases

In final version you should process the delay time given in Dwell(double time) call - meaning you should create state machine which waits until the delay expires and then set Engine->DwellTime = 0;


void MyDeviceClass::HandleSequences(void)
{

....

  switch(sequence)
  {

      case SEQ_DWELLING:
      {
         if(GetTickCount() - DwellTimestamp > DwellDelay)
         {
            // Well, dwelling time has expired
            Engine->DwellTime = 0;
            sequence          = SEQ_IDLE;
         }
      }break;


   





28
Try to set    Engine->DwellTime = 0; in  ::Dwell(double time) call.

See code in my example which touches "Engine->DisplayLine"  as reference how to update GCode line

29
Ok, I have looked at it.

I strongly recommend you to use my virtual plugin as startup.I managed to get most vital variables setup properly, so it does simulate work ( have not checked it with your M3 code however).

I found out why your code stalls - you need to set "MainPlanner->ExternalStill = true;" once you finish your movement or you reset your plugin.
You also do not update line position, so Mach does not show properly GCode line position.

30
With RAR it is ok

Pages: « 1 2 3 4 5 6 »