Display for Laser/CNC mode



  • did some more tests,just try to use one of the uiactions from CustomEvents.h, think you´ll also get error message

    here´s my CustomEvents.h:

    #ifndef _CustomEvents_H
    #define _CustomEvents_H

    extern int cExecute(int action,bool allowMoves);

    #define EVENT_UI_EXECUTE(action,allowMoves) cExecute(action,allowMoves)

    #define UI_ACTION_X_UP1                  1500
    #define UI_ACTION_X_DOWN1                1501


    and this is my CustomEventsImpl.h :

    #ifndef _CustomEventsImpl_H
    #define _CustomEventsImpl_H

    int cExecute(int action,bool allowMoves) {
      switch(action) {
            case UI_ACTION_X_UP1:
            case UI_ACTION_X_DOWN1:
                if(!allowMoves) return action;
                PrintLine::moveRelativeDistanceInStepsReal(((action == UI_ACTION_X_UP1) ? 1.0 : -1.0) * Printer::axisStepsPerMM[X_AXIS], 0, 0, 0, JOGRATE, false,false);



    if i don´t use one of these actions it compiles, but if i use them for example
    i get error message until i insert

    #if defined(CUSTOM_EVENTS)
    #include "CustomEvents.h"

    to top of ui.h.

    same behavior when i select different controller (so my uiconfig doesn´t matter)
    may be you find the time to have a look at it
  • also tried arduino 1.6.6 and 1.6.8 , doesn´t change , actually work with 1.8.0.
    is there anything else i can do for checking?
  • I see the problem and will hopefully post a update on github today that fixes it.

    Problem is you are using part of your custom file before it is included. Your solution is not really good as you now include it much too early so not everything you might need is defined.

    My solution is to move some more stuff to DisplayList.h which was in ui.h and put that part after the include of CustomEvents.h so you can use the defines in display definition.
  • edited January 12
    ok, thanks for support, so i guess the felix event system works as it uses the additional defines later on via menu?
    so i don´t have a felix printer and also don´t know about the hardware inside.
    may be you can explain a little 
  • Ok, latest update should now allow compiling without special tricks.
  • Ok, I already downloaded ;-)
  • You need new config to compile - added some new params for preheating.
  • Thanks, i´ll just merge my setup into new config
  • edited January 14
    Nice !
    No Tricks necessary to compile :-)
    During merging my adds i  found German translation " Kontrolle" for "control" , i think "Steuerung" would be better translation.
    " Kontrolle" in my understanding happens after a finished action.Anyway, that´s peanuts.

    You once more did a amazing job !

    so i can continue playing around with that stuff , I´ll concentrate to the Customevent system now , think using that will make my life easier
  • You are right, Steuerung matches much better.

    Yes event system is what everyone should use to extend functions so updating is easy. If there are hooks missing it is easy for me to add them. I think the Felix shows nicely what is possible now. Even new menu with translations are now possible:-) But that is a bit of a pain as you never see new menu entries. But still better then always putting your changes to updates.
  • Ok, have now merged some of your improvements namely laser warmup and door handling.

    I don't see why you introduced another door handler for this, so I modded it to use normal door already predefined to disable laser faster. Hope it works.

    I also modified the laser warmup a bit to make it work more general, but the main parts stay the same. Could you check if it is working as I have no laser with a delay I would notice.
  • edited January 31
    Simple reason for second door handler is if safety door is for example just a cover with a switch on Laser Toolhead
    and has nothing to do with machine housing.
    it´s let´s say for more professional use as it´s a safety switch assigned to laser , not to machine itself.
    So it makes easy to meet "Maschinenrichtlinie".
    As result you have one door switch for machine (might be useful for FFF for printing ABS or other high warping
    materials)  and one for laser toolhead.
    Checking will take some time , hopefully next weekend
  • edited February 1
    So i found time to do some tests in breadboard setup.

    Laser Warmup is not working as it should, it works as delay, moves and laser start at same time.
    (just set warmup time to 1000 , so you can see that clearly)

    Door " works" if you mean disabling laser immediate, but i miss message in display and also to host
    that door is open.
    As door is active in all modes i´m not happy with that. basic idea was just for laser mode and as i wrote above
    that was the reason i introduced a second "door" declared as laser safety door.
    For CNC  the door funktion should allow moves in order to adjust workpiece coordinates it should just block spindle enable.
    And for FFF , how to change filament with closed door or otherwise how to feed filament when door open and no moves allowed?

    so to be honest for me the new door function is not practicable, may be we should keep the second one just for laser.

    what do you mean?

  • edited February 1
    found bug with delay : (twice in motion.cpp)

                      //LaserDriver::changeIntensity(cur->secondSpeed); //doesn´t work this way
                      LaserDriver::changeIntensity(255); // need to switch laser on during warmup
  • Did you also take a look at the Display regarding workpiece coords(including G92 Offsets) for cnc and laser

    instead of temperatures?.

    i introduced 3 placeholders, translations etc. are done.

    would be nice to have it implemented as i can´t manipulate UIDisplay::refreshPage() update from custom Event.

    may be we can do it as Feature, something like #define Feature_WorkpieceCoord

    to activate that

  • I think for laser/cnc it is more common to use offset coordinates as you need to calibrate object position with G92. So I think we can switch to offset coordinates in cnc/laser mode so it appears for x/y.

    We now also have filters for different modes
    #define MENU_MODE_FDM 128
    #define MENU_MODE_LASER 256
    #define MENU_MODE_CNC 512

    only problem is default pages do not support them as they are not menus and always have a fixed size so disablinga line is not an option here.
  • edited February 2

    may be you misunderstood, so may be you find the time to take a look at the UIDisplay::refreshPage()  you downloaded from my site.

    that works fine and coords are shown as wanted.even Z is important as in CNC often workpiece height is set to 0.

    (when milling pockets for example).

    Any thougts to my comments regardin implemntation of door and laser warmup from my previous Posts?

  • Just changed %x0-2 to G92 coordinates for laser/cnc so it appears everywhere in that coordinate system, also in move xyz.

    I see now you have replaced the extruder/bed place with Xw/Yw/Zw (why w?) Might be an idea to have both on startscreen and G92 modded everywhere as this is more helpfull after calibration.

    Have reset power to 255. Since it is really warmup it should maybe really in full power until the move sets it back to correct power.

    Door seems difficult since it depends on printer type and user wishes. I know printer vendors wanting to disable everything if door goes open. Also stopping moves and not only stopping spindle would often seen as good idea, but making movements impossible might sometime be a problem. Ans some printers need open case to change filament, others not. So for perfect fit we need 3-6 extra config parameters to define how door should operate under which conditions. Not what I really like as users already find we have too many options.
  • edited February 2
    Yes, thats what i wanted to have , left side G92 coords and right side machine coordinates.
    just like "real" cnc machines mostly have.
    that´s why i added %x5-7.

    and you´re right door implementation is mostly point of view, so what about something like shifting door
    to event system, just have no idea how to realize.
    for me it´s ok to have it , anyway i can change or add my own version .
    so as your code is much more efficient as mine i´ll follow your example.

    As i read in posts from other users pwm for drivers is wanted sometimes, and i know
    we are limited on timers.
    Im working on external PWM, have it running already (and yes, i made that in Event System :-)  )
    I´ts  a buyable module based on TLC 5947 which gives 24 free running pwm´s in 12bit resolution.

    so it would give capability for easy laser and spindle control and may be also useful for the guys
    playing around with led stuff.
    For myself I´ll use it for step down voltage conversion , trying to get real dc voltage for Fans

  • Quote:
    I see now you have replaced the extruder/bed place with Xw/Yw/Zw (why w?) Might be an idea to have both on startscreen and G92 modded everywhere as this is more helpfull after calibration.

    BTW, the "w"  is for work coordinates  .

  • edited February 4
    please set ( in drivers.cpp  ) bool LaserDriver::firstMove = true;
    so we catch warmup also after homing.
    (needed if we home machine and start with G1)

    answered your last comments in previous 2 posts , what do you think about?

    may be youáre interested in that stuff https://sites.google.com/site/dtrlpf/home/flexdrives
    they now added data for startup delay , so i wasn´t wrong with my measurements ;-)
  • Ok have changed to true for next update.

    I also see your delay of 30ms in one of them. So bigger lasers have this. So now I'm wondering how to handle things like laser images work with such a high delay and if that delay is also valid for disabling. I'm a bit confused since laser are not my expertise. All I have is a fast blue 2w laser diode.
  • It´s quite simple it´s just during power up and depends on the driver electronics, not on laser itself.
    switch off delay goes ->0 as its maximum buffered by small capacitor.

    so laser images are often done adjusting brightness via moving speed.

    And TTL-modulated Lasers are "powered on " the complete time, so thats why need the delay just on first move.

    i also have only 3W laser which is not modulated so i think our solution with the Laser warmup catches both delays.
    the first one is the startup delay of laser driver (i´m shure youre laser driver also has some) and the second one
    which depends on material.

    so all my testing showed we´re on the right way ;-)
  • edited February 5
    Just a question regarding Door:

    shouldn´t there be a message when door open?

    as far as i understand  GCode::keepAlive should send a message
    (GCodeSource::printAllFLN(PSTR("busy:door open"));)

    but i cannot see ??

    i use Repetier Host 1.6.2

    so that part should send message i think:

     else if(state == DoorOpen) {
                GCodeSource::printAllFLN(PSTR("busy:door open"));

    so if i add       Com::printWarningFLN(PSTR("door open"));
    i get warning message as expected in keep alive interval

    but GCodeSource::printAllFLN(PSTR("busy:door open"));
    seems to do nothing ???  
  • busy: tell hosts why communication is not possible so it does not time out. I guess I should make host show this on manual control info box, so you know what is going on. In log it is filted with ACK filter.
  • Ok, that explains why i couldnt see anything.

    So may be it would be useful to have it as you wrote  and additional on Display for the case of SD printing

  • The display is an idea. There are 2 ways - as complete info window blocking any action or we could just change status message at the bottom. Also communication is blocked you normally could move with display controls when open. At least I think it is possible. Have no printer with open door sensor.
  • Think Status message is enough , and as host is already blocking we could add this to gcode::keepAlive()

    may be as warning message as i added in my test.  so i think it´s clearly visible for everyone and also working with existing host software

  • I agree except I do not like to repeat warnings. Have just committed a patch that stores door state so it sends warning only once. It also sets status to door open, but that might get deleted after a while from the next status message. So maybe we need to move that to a test if enabled or in busy so it gets only updated every 2 seconds after first appeareance.
  • tried to merge the changes in ,
    get error message

    exit status 1
    'UI_STATUS_UPD_F' was not declared in this scope

Sign In or Register to comment.