I have a pendant that I built with the help of Leo Urtiz years ago. I would like to use it on my newly rebuilt Primo. I don’t think Leo is active here anymore - correct me if I’m wrong - so I’m hoping for some advice on hooking this up to the new build. The pendant is still connected to the old Ramps board, and it looks like it just has four wires connected to Aux1. Since two of those pins are 5v and ground, I’m thinking this is a UART connection, with the other two pins being Rx and Tx. Does this sound right?
I do know that the code on the pendant builds strings of gcode commands and sends them out the serial port.
My new build has an SKR Pro 1.3 in it, which as a set of dedicated UART pins. I’m wondering if I can just connect to them, and if I need to make any changes to Marlin to get them to work. Anyone have any ideas? Thanks for any insights!
We configure two uart ports on the skr pro. 1) the USB, which you can’t use and 2) the tft uart (1x5 pin header, with rst) If you don’t have a fancy touch screen, or you want to use the touch screen in only the marlin mode, you can use those pins.
If you do have a tft, I think there is a uart input on the screen. I haven’t tried it before.
There is another uart, designed to be used by a tiny wifi card on a 2x4 pin header. But that isn’t enabled in the firmware. To add it, you have to edit the SERIAL_PORT_3 to be 6. Or something very similar.
This is exactly how the tft touch screen works. I honestly think it is a little flawed, because there is no guarantee that the gcode being sent is being received. I don’t have a problem with jog commands, because the user can tell if something went wrong. But I don’t like the idea of sending gcode patterns over uart like that. But… Octoprint works fine (over USB, which is a little different).
This sounds like the approach I want to take. I’m using the pre-compiled version right now. I take it I can download the source code with all the V1 settings pre-configure, and then make your recommended change on that, and then recompile? Just want to make sure I don’t have to configure the whole thing from scratch (I know you wouldn’t do that to us, just making sure).
It is my understanding that Marlin is acknowledging each g-code command that it receives. I just don’t know if the g-code senders make use of it. I would think they would have to in order to avoid overfilling Marlins internal buffer.
Yes. It can be found at MarlinBuilder releases. The zip you download has the .bin in it for the already compiled version. Your is something like V1CNC_SkrPro_Dual. It should have the same short version string (513D) when you’re done.
I would build it without changing anything first, to make sure your platformio setup is correct. And then make that change.
It sends ok\n. So if the TFT was trying to send G1 X100 and it was received as G1 X200, then Marlin and the TFT have no idea something went wrong.
I can also be the case that ok\n doesn’t get received by the TFT, or it gets received wrong, and then the whole sending process halts.
These are very rare issues. But with hundreds of users, it could be popping up. IDK if you remember those issues in the forums, but we were recommending using Marlin mode since then. There was a bug report in the screen firmware that explained some of it. But I am still worried the fundamental issue is with the actual design.
The gcode standard also supports checksums. So it is possible for the tft to add those. Marlin can be configured to check them. That would be one step in the right direction.
The whole thing is a bit paranoid, honestly. We aren’t driving a space shuttle.
I already had VS Code installed. I added PlatformIO. I downloaded the code, unzipped and opened it in PlatformIO. I don’t see the checkmark mentioned in the PlatformIO docs.
I personally can’t help any. I don’t use platformio in vscode, I just use the command line. The instructions linked when you type platformio should work though. They are often used. If there is a mistake in there, then we need to fix it.
Hmm. There’s no mention of Auto Build Marlin in the instructions I used. I have added it now, though. I have the M icon on the left. No matter what file I highlight and click the M, I get this:
The first button would simply bring up the “File > Open” dialog for you to tell VS Code which Marlin config folder you want to work on. That’s the one to start with. You must have a copy of Marlin opened to edit.
Hmm. You do seem to have a Marlin folder open. I’m not sure what to tell you except to say that the following screen shots are me going from (1) first opening VS Code (2) clicking on “M” at left for ABM (auto build marlin) and (3) clicking to open the ABM panel:
In looking closer, it looks like you might not have opened the right folder. In my screen shots, of the two Marlin subfolders, the upper one is at the top of my folder browser on the left, while in your screen shot, some higher parent folder (with a long name) is at the top. I think you need to drill down one level deeper on what folder you have open.
Ah, good call! I closed out what I had, and drilled down one more level and now I get Show ABM Panel.
I get these messages in the lower right - are these requirements? Dependencies? Just suggestions?
I know what Git is and I don’t mind adding either of these, I’m just curious as to whether these things are required or not. An earlier message of this type had me install some C++ thing and I didn’t know if that was required either.
Okay. I’m sure I’ll learn soon enough if I chose the correct options.
Thanks for your help!
Oh, one more thing - I’m not sure what to make of these options. Can the SKR Pro be updated from a USB drive? Or through the USB port? Or should I just put it on a micro SD and put that in the board? I’m not sure how to update board.
The SKR boards get their firmware by placing the “firmware.bin” in the root of an SD card, and inserting the SD card into the board, and booting up the board. When the firmware update completes, the board boots on up, and the “firmware.bin” file gets renamed to “firmware.cur” — in which “cur” means “current” and indicates the current firmware is the updated firmware.
