Advanced Search

I managed to get Remora uploaded to an NVEM v5 board, thanks to Scott's detailed video instructions. The board has the RT1052 chip and I was able to make a donor STLink into a DAPLink and upload the firmware by compiling the latest Remora-RT1052-cpp source. I could see it working by toggling the eStop in software and seeing the LED light up on the board so I know it was responding to LinuxCNC. Just like in the video. 

I then successfully uploaded the full_config.txt with the upload_config.py script, I managed to get past needing to install the TFTP package via PIP successfully. I did manage to get the config file (the supplied unmodified config) uploaded to the board the first time but now I'm trying to make updates to the config and it no longer uploads. The script confirms it's valid config, but now I get a time-out error. I can still ping the device and get responses, something else is blocking it. 

I've already de-soldered the pin headers - and packed away all of my soldering gear. I could re-solder it and re-flash with a fresh firmware, but ideally would like to avoid that in case this happens again.

Seems the board is now bricked and won't accept new configs. The LED eStop indicator on the PCB is lit permanently and I can no longer toggle it in software.

Any ideas how I can get this up and running again? I've tried to be as specific as possible. I'd love to share some screengrabs and stuff, but the system is set up offline in another room. Let me know what I can provide to troubleshoot? I can get the computer connected to the internet to share configs and logs and other bits and pieces if that helps. Just thought maybe someone knows an obvious answer?  

Thanks for support.

Interesting, hopefully we will see more pictures along the way.
Maybe turn the linear rail upside down on X?

tommylight wrote:

Yeah, i would not use light switches...
-
Take the "unknown" idea and combine it with mine, that would be the best solution possible.
Total cost would be under 20$ and provide actual safety, something you do not seem interested in.
 

Hi tommylight ,

Thank you. I am learning bit by bit, these are over my head. I understand that we should have fuses or circuit breakers to protect the circuits.

Best regards,

...behai.

Hey guys. I just wanted to show off my new build in process.  


Rf45 type machine, to be cut up and built back. 

imgur.com/5rXfGbQ

Basic premise... 

imgur.com/09rXoGL

imgur.com/a/Er23Lcq

My cables are ~3in/7,5cm long and i use a Rpi 4b with the official LinuxCNC image.
Tried it with the jumpers in UART mode and the config from below, still the same error.
It tries to connect to the TMCs but fails according to the debugging.
Maybe my pin names for the rx pins are wrong but i can't find them in the BTT docs, only the CS pins are there.
  .

Yeah, i would not use light switches...
-
Take the "unknown" idea and combine it with mine, that would be the best solution possible.
Total cost would be under 20$ and provide actual safety, something you do not seem interested in.

unknown wrote:

I probably when OTT with power supplies.
What I did was use some light weight DPDT relays, one set of contacts latches the relay after briefly being energised by a pushbutton and the other set of contacts controls a contactor with a 24v coil. I find this a great because if the power is removed, blackout breaker tripping, and comes back on the power doesn't come back on.
I went with a relay > contactor setup as I wanted to keep the 240 seperated from the 24v control. The only issue is that there is an always on 24v supply dedicated to the relays.
To clarify there's one relay/contactor per power supply. Each power supply can be independently controlled. For wiring the latching relay I had some PCBs made to simplify the wiring.
Bit more involved than a 4 way gang switch. The same thing could be implemented with a NVR switch for each PSU.
Oh I forgot I'm series with each pushbutton is another switch, this is used to turn the relay off and has to be in the "on" position before pushing the button to turn the power supply on. It's kind of like starting a rocket.
 

Hi Rob,

Thank you very much for your explanations. The first solution is way over my head

I am going to study the NVR switch. They look better than 4-gang switches and more accessible, too.

Best regards,

...behai.


 

Thank you @tommylight and @unknown ( Rob ),

I appreciate your suggestions. I have learned of this set up from this YouTube video from the thehardwareguy channel.



Please see from 5:40 to 07:50 -- he uses a 2-gang switch, even though he has 2 PSU and 1 VFD.

Best regards,

...behai.

 

This has gone a bit sideways, hence my restraint to delete it, so vote?
Me voting:
all the same!

On the main to the left of the DRO axis labels - the group of buttons
 

25:1
20:1 or 30:1 as i fully agree with Rod and Snowwy, it gives a better working range, although it will be very hard to actually see any difference in normal use, but might be noticeable at very high feed rates as it would track better the surface of the material. Never actually tried to notice as no plans for it, it works and it works very good.

Found it


forum.linuxcnc.org/show-your-stuff/30648-rugbot-1000

If i understand correctly the "MDI queue", i se no reason for it, ever.
It is a simple as manually editing a file and open/run it in LinuxCNC, and i do this a lot.
Once opened, LinuxCNC has also the option to edit it from the file menu, removes the need for looking for it on the drive. LinuxCNC can also edit any opened file, granted the correct text processor is set in the ini file.

thanks, It's work perfectly now