Not connecting with new release Umikaze 2.2.1RC3

[cyberjunkiefr]

Hello, I'm still working on my Hotwire 4 axis cnc machine. I'm using a BBBW with the replicape. Yesterday I've downloaded the latest umikaze 2.1.1RC3 and installed it on my system. Everthing went great until I tried to connect, then I've got no connection.

I've seen this before, redeem doesn't connect if there's an error in the CFG file. But I didn't install my machine cfg yet and I was just using the default.cfg. So I uploaded my local.cfg file that I used on my working umikaze 2.1.0. That didn't connect either. I took a look in the journctl for redeem and there where warnings that some things where not found in the default.cfg. So I took the Default.cfg file that comes with the RC3 and changed the values for my configuration and deleted the lines that I didn't need to change. Still the same no connection. I really don't now where to look for and what is going on. I uploades the log files and also the journalctl for redeem (rja.txt) I also uploaded the local.cfg that I've used. I hope someone can help me. I've been working on my machine for 1.5 year now. Of cause it works with a simple 30$ MKS base v1.5 but that's not what I want. When I talked to Elias Bakker concerning my project He told me that the replicape could be used for cnc (5axis) without problem. I still believe the hardware is more then capable. The combination of BBBW/REplicape is perfect for a standalone cnc controller of quality. I've tried to put Machinekit on the system, I've got machinekit and machine client running but no way to hook up replicape to machinekit. So I went back to umikaze that was the first thing I've tried as I got the system. I don't use octoprint but only the terminal and the filemanaer to send gcodes to redeem. But still I got troubels with homing on 4 axis. finally I got that working (see my post). Then I tried running the machine. This machine cut's profiles out of foam at a very slow speed (F60). when running a gcode like this: G90 G1 X600 Y50 Z600 E50 F400 G1 X0 Y0 Z0 E0 F60 Then the first movement will be perfect and precise but the second movement will stop to early. The position will alwas be X47 Y26 Z47 E26 and M114 will show al axis to zero. I can run it again and again and always the same. I've been thinking that meaby a watchdog or timeout problem so I disabled the timeout and the watchdog in my config, but that didn't help. So I've been thinking that redeem has trouble with the ulta low speeds. In fact If I run both movements at F400 then I can run it over and over again and everything is perfect. So that's when I decided to go to the new version hoping this would be solved. NOT AT ALL. Redeem might just not be ok for CNC. It's missing all that's necessary for CNC,, M3, M5, spindel managment, PWM to one of the mosfets with the M5 command. Take a look at GCODE: most programs (Fusion 360, jedicut, devwing foam, Sketchupetc) that generate gcode for cnc use Fxxx to set speed.

I always have to change the Fxxx to G1 Fxxx.

I believ in the BBBW/replicape combination and if I can help solving the problems and making redeem work with a cnc I will gladly do so.

I have a machine with 4 independend axis that I can use to test anything that you guys want to trown at it. Maybe I could get rid of octoprint and make a new interface (like Grbl panel view) to interface with redeem. I would need some more information about how to interface with redeem and how to set up an ubuntu image with only redeem on it.

Thanks a lot for any help i can get

Roel Jaspers

octoprint.log plugin_redeem.log rja.txt serial.log

[Wackerbarth]

Thanks for your report. I'll try to address some points. downloaded the latest umikaze 2.1.1RC3 and installed it on my system. Everthing went great 👍 until ... no connection. 👎

redeem doesn't connect if there's an error in the CFG file -- Correct, Redeem aborted because of configuration issues. I have some changes that will address this problem. But they were pushed back to the next release.

I hope that you did not edit the default.cfg . Please post the local.cfg that you are trying to use. From the messages, I can see that you need some changes to it.

WARNING Option travel_y in section System does not exist -- These options are in the Geometry section of the configuration. You must add section headers ([Geometry] and [Steppers]) to your local.cfg. Look at the default.cfg for the general layout.

There is a problem with some default-fan-{}-value entries. Again, knowing just what is in your configuration files is needed.

Also, depending on how you did the installation, we need to determine if you have the proper default.cfg and not an older one. Does you version start with ### Default Configuration [Configuration] version = 1

[cyberjunkiefr]

Hello again, This the error I find in Systemctl status redeem:

I could find the file to check it.

Thanks

[Wackerbarth]

Yes, please post the local.cfg. Although you intended to do so, I cannot find it.

[Wackerbarth]

As to the issue of the missing gcode functionality, the current intent of the development was to attempt to emulate the "Marlin" variety that is commonly used in 3D Printers. However, I don't think that it would be very difficult to make the "language" pluggable and support the version of the gcode language that you describe. Most of the codes and implementation would be identical and the differences can be handled by having alternate dictionaries of implementations.

[cyberjunkiefr]

Hello Wackerbarth, I was on travel so I couldn't answer you. First of all thanks for the quick response. Hereby my local.cfg file, sorry for that. This one was made from a copy of Default.cfg. I've edited the lines I need and deleted the line that are ok. Of cause I didn't change the default.cfg file. I've loaded the local.cfg twice as explained in the manual, to prevent from having an empty file. This weekend I had some time to test, so I downloaded 2.2.1RC3, 2.2.1.RC2 and 2.2.1_dev4. I've loaded these version on SD with etcher and I booted the system with those SD. Everytime the image was loaded to the EMMC, to make sure the system was clean I've loaded the new Local.cfg (created from Default.cfg) file twice. But all the 2.2.1.xxxxx version just didn't connected. On all versions I also loaded my local.cfg file that worked with the 2.1.1 version but that didn't work either. I was expecting that because I've compaired the two files and they where identical (Headers and everthing.

Finally I went back to the latest 2.1.1 version I've used before and that worked! I used the same new local.cfg file for that test. I big difference is that the 2.1.1 version will show in the connection part "dev/Octorpint_1" and not AUTO as in the 2.2.1 versions, meaby that might help.

The reason that I wanted to go to a newer version was that at the ultra low speeds I use (F60) that version would fail after a certain time (a couple of minutes. That's still the case, but by testing at higher speeds I found out that over F85 the system would work just fine. the 2 failures I would have are: 1: If I would use this gcode: G90 G1 X600 Y60 Z600 E60 F350 G1 X0 Y0 Z0 E0 F60 then the machine stop at the wrong position and M114 would indicate all axes at zero. In this case the system is still running and a G28 X0 Y0 Z0 E0 will work ok.

2: When running a complete GCODE (look at my first post) than the system would stop at some position, while the terminal screen shows that the GCODE was not completely finished. In this case a restart of redeem (and sometimes a reboot) is necessary to get things going again. I can run the GCODE over and over again and the system will always stop at the same position and even the the terminal screen shows the same line of GCODE. Cutting a wing profile will take about 8 to 9 minutes. The programs that I use to for generating the GCODES of the wing profil are JEDICUT and WingCode. Both have the same result at F60. Jedicut will generate relatif GCODE and WingCode will generate the code in absolute GCODE. As I said before I really like the BBBW7Replicape combination because it's quite, standalone and super quality.

The GCODES I'm really missing would be M3 (start spindle) and M5 S2024 to set the PWM of one of the mosfets (in preference the hotbed mosfet). Another thing that would be great is a possibility to NOT use M105 ever so many seconds , I did put the time between two M105 at 500sec. I can still see some warnings in the logs about the temperature of the hotend/hotbeds being at 0.0°. I possibilty to disable all temperature checks would be a plus for a CNC machine.

Again thanks for the good work, and if I can help and test on my machine then I'll be glad to do so. If I can have some information about how I can interface with REDEEM without octoprint, I could try to make an interface espacially for 4 axis CNC machines.

Roel Jaspers

local.txt

[Wackerbarth]

Now that I see your local.cfg, the problem is obvious. First, with respect to the various 2.2 builds, totally forget any of them but the latest (RC3). Although you were attempting to do some regression for us, the problem is that you deleted a very important line in your local.cfg. In particular, as I mentioned previously, the "Geometry" section header, line 26 of the default.cfg, is needed after line 5 in your file to place the "travel_x", etc. parameters in the proper section.

As to replacing OctoPrint as your User Interface, depending on where you run that program, there are two possibilities. If you run it on the BBB, it can connect to the offered serial port /dev/octoprint_1. Alternately, there is the ethernet connection on port 50000 to which you can connect with a terminal (telnet) or a program that has the capability to make such a remote connection.

We have in the pipeline both an enhanced customization of the thermal handling and the idea of adding additional modes to connect to the program. Both of these should make it possible for you to create a better experience for your CNC usage.

[cyberjunkiefr]

Thanks so much Wackerbarth !!! I compaired the 2 files twice but didn't see that I missed a header!

I'm trying this out this evening and get back to you with the results. I'm running Octoprint/redeem on a BBBW so I also have WiFi (I think that's also on port 50000). I'm waiting patiently for the new idea's. Being able to create a new "CNC" interface for 5-axis (X,Y,Z,E0,E1) would be super great. It would take the BBBW/Replicape to a different level. Especially because there's notjing much for 4 or 5 axis cnc machines. Except for some parallel/usb board on MACH4 or linuxcnc (which cost like a fortune) that's it. Most boards are 3d printer items, but heck they can do CNC on more then 3 axis. As I said I can help with testing and I can't meaby help building a new interface software that's CNC oriented.

Can you tell me if there's a way to not send M105 codes every xxx seconds?

Thanks for the good help

Roel Jaspers

[Wackerbarth]

The M105 codes come from OctoPrint. They may have an option that will turn them off. But, since a 3D printer needs at least one heater, they may not. I cannot help you with those options because I never use OP for any device that does not have heaters.

[cyberjunkiefr]

Hi Wackerbarth, I got RC3 up and running and performing perfectly. I found another issue in the local.cfg file: this doesn't work anymore. So I took it out and just change gcode script for conneting from M106 to M106 P0 S255. Which does the same trick.

In your last post you said: "I never use OP for any device that does not have heaters." but what do you use indtead then?

Thanks very much for the help.

Roel

[goeland86]

@cyberjunkiefr with regards to your fan configuration segment - from our perspective as developers, this would be considered a bug if it actually worked initially... The reasoning is this: if you have a fan with a default value, then its state is managed outside of the M106 framework. The default values were meant for fans that should be running constantly, or for fans meant to react to temperature readings (i.e. the hotend reaching a certain temp on a 3d printer). Perhaps Redeem is too 3D printing centric for your current use-case after all.