Closed amoineau closed 3 years ago
amoineau
commented
3 years ago Ok for the setup.
We are using a custom board with an atmega 2560. I used the check box option a few weeks ago to debug something but I forgot about it since then, good idea.
The USB cable was my second option, what's more we use a USB hub of questionable quality because we have 3 serial ports total in the machine. I'll test a more direct approach, with other cables.
Thanks for your help once again !
svenhb
commented
3 years ago I added the serial COM setting also... Hope it will not make problems when loading a setup.
amoineau
commented
3 years ago I didn't want to force your hand ! ^^'
Did you receive my email with the pictures ? I should be able to re-take a video tomorrow or Wednesday of the single-page operating.
Concerning the "reset", I ran tests for an hour this morning but the problem didn't occur once... So I can't really track it, it's very ironic and frustrating. But i remembered something, in the CNC serial monitor I always had "Pn:RHS" blinking. At first it bothered me, but then I decided to ignore it because I couldn't find where it came from and it didn't seem to cause much harm. Do you have any idea why I have that and if it can be related to my problem ?
svenhb
commented
3 years ago Sorry... Yes I received the pictures - impressive. Video would be nice, but is not a "must".
Pn:RHS: Pn:XYZPDHRS indicates which input pins Grbl has detected as 'triggered'. D H R S the door, hold, soft-reset, and cycle-start pins, respectively. Check: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface#grbl-push-messages
Perhaps you have "open" Hold-, reset-, cycle-start-pins? Not connected to ground (or Vcc). You may check the pin-assignment of your grbl-firmware... Example: https://github.com/gnea/grbl-Mega/wiki/Connecting-Grbl-Mega
amoineau
commented
3 years ago Sorry I wasn't very explicit with my question, I did find what the symbols meant, what I didn't know is why do they occur. On our board, the control pins on Port K are not linked to anything after the MCU, except for K3 (Safety Door) which is linked to our emergency stop, so in my mind all the others are supposed to be at 0V.
So the two things that I don't understand is : How can they be triggered and why isn't it a problem (albeit our recent "reset" problem the machine works fine even though the RHS seems to be triggered constantly.
amoineau
commented
3 years ago I'm asking you all these questions because you master grbl but you really are in your right to tell me to go bother someone else with my problems, I would perfectly understand considering it's not your job and you have already spent a lot of time helping me !
svenhb
commented
3 years ago No problem...
so in my mind all the others are supposed to be at 0V
Without shematic of your hardware, you never know. Also I don't know if internal pull-up (or -down) resistors are available and used... Better connect the open pins to the needed potential (probably +5V) via a resistor (10k)...
amoineau
commented
3 years ago Without shematic of your hardware, you never know. Also I don't know if internal pull-up (or -down) resistors are available and used...
I'll check the schematics again with our electronic guy but he told me that the pin should be connected to the ground.
Better connect the open pins to the needed potential (probably +5V) via a resistor (10k)...
Indeed I told him I was not a huge fan of open pins, I'm not proficient enough in MCU to be sure that not connected necessarily means ground. Plus it might indeed be +5V for "everything is ok".
amoineau
commented
3 years ago We are still looking into the reset problem but I see no reason to keep this issue open, every enhancement has been implemented and tested. Great job and thank you !
Context
I'm working on a laser cutting machine but the purpose is to cut shapes of fabric longer than the machine. We use a conveyor with an arduino board to move the sheet between cuts. The addition of the "tile" feature is really fortunate for us.
I added a second serial communication to GRBL-plotter in order to communicate with the arduino board. However, right now I have to manually hold the process at the right time, send a command to move the conveyor and resume the process.
Requested feature
I wanted to know if there was a way for me to put the process in hold between tiles while waiting for the conveyor.
The procedure would be : (Plotter) Do tile n > (Plotter) Send "top" & wait > (Arduino) Read "top" and moves conveyor > (Arduino) Send "top" > (Plotter) Do tile n+1 > loop...
Ideally the GRBL would be homing while waiting for the conveyor.
Thank you for your help !