Closed phil-barrett closed 4 years ago
It goes on my wall of shame I keep to remind me to think before acting.
You are not a alone, I have a small collection of boards killed by beeing careless. I have managed to fix a couple by replacing the CPU.
If you want one, will send it to you, gratis.
Thanks, that would be nice - will enable me to help out with the ethernet code. Hopefully the Teensy will be back in stock soon, it wasn't a few days ago.
I assume there is still code to be written.
There is, the published code only allows changing the feed rate and spindle RPM overrides. Toggling between them is done via a switch. Enough to make @einencool happy?
I have tested with a cheap encoder used for UI navigation, it needed filtering. 100nF or optocouplers made it usable but not perfect. No bouncing detected when using optocoupler, but miscounted a bit when turned fast. I tested on my T4 with 150E diode current limiting resistors, 4K7 or 18K load resistors and a ILD615. 3V3 drive voltage.
The documentation is in error regarding pin routing beeing universal. Only a few pins are usable for the ENC peripherals. As a start the current code uses GPIO, this is ok for simple stuff like the overrides.
Unfortunately, I have pins 30, 33-35 as digital inputs so only one is on the list of flex I/O pins. Easy enough to change in the future - at least to get 3 of the flex I/O pins. They are filtered via a 15.9 KHz RC low pass filter. The R & C are 805s so fairly easy to replace if a lower cut off freq is desired.
I don't think a HW (or FlexIO) encoder is necessary for manually turned encoders though perhaps for a shaft encoder on a motor. There is a state driven quad encoder library that handles bounces as part of the state table - much more robust, by the way.
Strange that github doesn't have a private message capability. Send an email with your physical address to phillipDOTlyneDOTbarrettATgmailDOTcom and I'll put one in the mail for you. Probably some time next week. Will let you know when. You will need to assemble the TH components which are pretty common and cheap except for the MagJack (2 euro from Mouser, I'd guess). It also needs 2mm pinheaders and sockets if you want to not solder the teensy to the board.
Phil
@terjeio It would be nice to change the feed rate on the fly. How it is done, I have no idea what you are speaking of, but when it runs, I'm the happiest person in Germany :-)
Phil, what do you think, what time do you need for your next trials for the board? 3 of 4 motors have arrived and I think in 5-6 weeks it would be great starting to upgrade the machine :-)
With best regards Chris
I'll need a few days to verify the PCB after I get them so probably a week to 10 days. I don't know what intl mail is like these days. How long did it take to get the one I sent you?
No hurry, I have time, when you have to test your board, then it's better to get one, when everything is working like you would expect it :-)
I think it was around 3 weeks, but like I said, when I start upgrading the machine, I've to change the motors, the wiring etc. Then it'll get a Mist coolant, the vacuum cleaner and so on. I changed the game controller from the ps3 to a Xbox one, because it works better with windows 10...
Three weeks? Yikes.
I got the new PCBs back. Testing now. It seems to work pretty well. Just ran a simple encoder test and all 4 digital inputs work.
A dumb question, perhaps. How do I test it with grblHAL. In driver.h I have set QEI_ENABLE to 1 and added this at line 162:
#if QEI_ENABLE
#define QEI_A_PIN (36u)
#define QEI_B_PIN (30u)
#endif
I copied encoder dir to IMXRT1062/main/src and then rebuilt. No errors.
Now what do I do?
[edit] using Alpha 19 of TSender.
The feed rate override should change, it is visible in TSender:
Ov:...
is added to the real time report when changed so can be checked with a terminal too.
OK. It works. I would suggest dividing the encoder output by 4, though. Each click is 4 units. My 100 clicks/turn encoder doesn't get very far before the override is maxed (or minned) out. grblHAL sees a 90 degree turn as 100 clicks. My encoder hardware actually goes through a full quadrature cycyle per click and will report a "position" of 400 for a full turn of the encoder.
Also, it would be nice to have a way to change the apparent direction in grblHAL without switching the input pins (or rebuilding) since the user probably has a plug made up. Right now with A on 34 and B on 35 turning my encoder towards minus increases the FR.
I also note that sometimes it will show a non multiple of 4 in the change to Ov. As part of the full quad cycle nature, it is possible to read the encoder mid cycle. But the cycles always even out so you should always be seeing a multiple of 4 which just using the encoder output. I think this might be the source of the missed inputs you mentioned earlier. When dividing by 4, I have to save the partial cycle count. When I use the encoder library, I just save the partial back to the encoder. If I read 7, I report 1 step, write back 3 and pick it up on the next read.
[edit] the cheap 20 click/rev encoders I have also report a full quad cycle per click - ie 80 per full rotation.
My encoder is only 20 clicks/turn so matches better for override use... Anyway, $-settings are needed - will have to assign some.
I will look into the missing counts and adding optional hardware encoder (ENC) support when I get time, summer suddenly arrived here so I will be busy with painting my house and taking care of the garden for a little while.
Yeah, I've been spending a lot of time gardening as well. We have deer in the area so I built a 2 M tall garden fence for an 8M x10M area last month. Ibuprofen is my friend...
I'm ready to send the PCBs out so if you want one, send me your address.
The small mechanical encoders work ok but are very bouncy. I wouldn't be surprised if that is a source of missed or too many counts. I think the LPF helps a lot with that but I've bounces that last for 10 mS on my logic analyzer off the cheap one. That would take a pretty aggressive cutoff frequency.
Phil
On Tue, Jun 16, 2020 at 11:36 AM Terje Io notifications@github.com wrote:
My encoder is only 20 clicks/turn so matches better for override use... Anyway, $-settings are needed - will have to assign some.
I will look into the missing counts and adding optional hardware encoder (ENC) support when I get time, summer suddenly arrived here so I will be busy with painting my house and taking care of the garden for a little while.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/terjeio/grblHAL/issues/59#issuecomment-644942018, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6NUTVY3QXSZL22E3DX2ITRW63RHANCNFSM4N327HEA .
What type of rotary encoders are you using? I see on eBay many different types from 2€ - 60€ I think you are talking about the cheap "a rduino rotary encoders" for around 2-3€, which are not so good?
However, the work you both are doing is amazing, 💯 I'm so happy that I build the machine in this time so I could have some influence of the part, obviously I don't know what you are doing there :-) Greets Chris
I think you are talking about the cheap "a rduino rotary encoders" for around 2-3€, which are not so good?
IMO these are good enough for adjusting the feed rate/spindle RPM. Buy one that has a switch that is activated when pressing down, this can be used to toggle between feed rate/spindle RPM mode.
Ah perfect :-) I read about it with the switch.
Is it possible to configure the software that I can only adjust the feed rate from 0 - 100%? Because for me the override is not so important, it's more important to slow the machine down in the beginning and then set it up to 100%
Are these real time commands so that in one motion the speed will be adjusted or after clearing the cache?
Is it possible to configure the software that I can only adjust the feed rate from 0 - 100%?
The range defaults to 10-200%, defined in config.h:
Are these real time commands so that in one motion the speed will be adjusted or after clearing the cache?
They are real time.
Wonderful. I thought maybe it's possible only to adjust 0 - 100% with the encoder and in the software 0-200%, but it's alright :-)
I think you are talking about the cheap "a rduino rotary encoders" for around 2-3€, which are not so good?
IMO these are good enough for adjusting the feed rate/spindle RPM. Buy one that has a switch that is activated when pressing down, this can be used to toggle between feed rate/spindle RPM mode.
They do work though I wonder how long they will last in a shop environment. By the way, I've tested with an "Arduino" encoder with grblHAL and the switch works. Haven't tested index enable, btw.
Note that there is an issue with the first 5 axis PCB - the digital inputs are not 5V-tolerant. Not a problem for "Arduino" encoders. If you are using a powered encoder (optical), use 3.3V which is available on the digital input header. Even if the encoder specifications say 5V, it's likely it will work on 3.3V.
In my case the arduino Encoder will hopefully last for a long time. It's just for hobby use and I don't use it every day. And when it will be damaged I'll buy a new one for a few Euros :-) And I don't think that I'll use the switch button, because normally I don't adjust the spindle speed...
This issue has been fully resolved
Terje, I got my board working with digital input but through massive cerebral malfunction managed to apply 12V to my only T4.1. Seemed to not like that very much... Neither did the board it was plugged into. Sigh. It goes on my wall of shame I keep to remind me to think before acting.
Anyway, Got new Teensy 4.1 today and will be building another board. On a related front, I have a slightly different PCB in manufacturing and all the SMT parts will be mounted on it. Should get them early next week - this is part of my "unkit" plans. I will have a few extra. If you want one, will send it to you, gratis. Anyway, this one has working ethernet on it as well as 4 digital inputs with filtering and diode protection. One minor error - not 5V tolerant. I have a fix ready to go for the next batch, if there is one.
So, I'm looking into encoder input. Saw the files in plugins and the driver.c and driver.h entries. I assume there is still code to be written. I will be testing it stand-alone in the meantime.