pronterface/osx-yosemite/rumba no-go?

When I started the build, I had in mind that the machine would be in the vicinity of a Linux box. Hasn't worked out that way, so my only alternative ATM is a 2014 MacBook Pro running Yosemite.

My controller is a RUMBA.

..., and neither Pronterface nor Cura want to talk to it.

The usb-serial ports show up, but unfortunately Pronterface only reports possible baud rate errors upon connection attempts..., etc. Cura simply fails during the auto-probe and doesn't do much of anything when explicitly set.

Marlin's Configuration.h shows a bit rate of 250000, which I've set in both the host applications. Nada.

Doesn't matter which USB port I use.

Interestingly, the Arduino IDE has no problems.

About the only two easy options I can think of are to try reducing the Configuration.h setting..., though I'm doubtful of that simply because Arduino IDE IS working. Not sure that is quite relevant though simply because I assume it's NOT Marlin that's running when Marlin is being uploaded.

Could also try earlier versions of Pronterface..., but that seems doubtful simply because problems talking to OS/X show up fairly regularly in the post-Lion era, so what's the likelihood earlier versions from that era are gonna work...

Any thoughts?

Thx!

So I set the firmware's bitrate down to 115200 and re-uploaded it.

Now pronterface can at least connect with the printer, however; it sucks.

The communications is so error prone and glitchy that it can't even ping the printer for status at a low rate w/o a constant stream of errors. Attempts to print fail miserably, however, that looks like it MAY be pronterface's problem, since it complains about not being able to find some character encoding related something or another. Will look at that one more tomorrow.

XYZ slew operations generally work OK..., setting temps works OK,

Still..., it would appear that getting this hardware/software combo talking is gonna be a long slog.

It IS usable enough for debugging/fiddling and manual leveling operations, but not much else.

Boo.

OK.

The test cube appears to be printing correctly via pronterface over USB.

Not quite sure why the data corruption errors have disappeared, although I know that Pronterface and the RUMBA can become confused about who is thinking who is in what state. I'm guessing as things were incrementally set right AND power-cycled, things became happier.

So, to make the following work:

• Pronterface (Feb 2015)
• Slic3r 0.9.9
• OS/X 10.10.x aka Yosemite
• MacBook Pro (vintage early 2014)
• Makerfarm I3V w/ RUMBA

Something like the following needs to happen:

• In your Marlin Configuration.h, use the following:
  
  • #define BAUDRATE 115200
  • ..., and re-upload. (Sorry!)
  
  
• ..., and use 115200 in Pronterface.
• Enable Pronterface's Slic3r integration more or less as described by:
  
  • http://forums.reprap.org/read.php?4,363055
  
  
• Restart Pronterface.
• The Slic3r dropdown should now be available, with all the configs you "migrated" to the Mac app library properties thing.

The key for me was the migration of the config stuff. The coupling between Pronterface and Slic3r is a little funky. It might help if Pronterface were to aid with this migration somehow.

By migration, I mean that by whatever means, the Slic3r ".ini" files need to be installed in the appropriate locations in:

• ~/Library/Application Support/Slic3r/(print and filament and printer).

I found the easiest way to do this was to run Slic3r, do the desired Load Configuration, and then go to each individual sub-config and save it with a new name. The stored copy will end up in ~/Library/... Ya do that for the print, filament, and printer sub-configs. You repeat the process for each entire config you want to migrate. When you restart Pronterface, it will see them, and let you select whichever you want for the configuration passed when invoking Slic3r.

Of course, you may not care about the Slic3r integration, but I thought it was at least worth knowing how to make it actually work.

One nagging problem is that Pronterface doesn't seem to have control over the host machine's power management, aka sleep functionality. The "pronsole" reports some kind of missing something errors regarding sleep..., and so..., even though id kinda tries to prevent it, the machine will sleep according to its usual power management settings, and rendering from Pronterface will halt when sleepy time hits.

Still..., overall..., Pronterface w/ Slic3r integration is now at least useful.

Gotta say though..., glad I have an SD card... ;)