LiveCode Forums

I am trying to control a 3D printer from LC.
It is attached to my current model Mac Pro (10.14.2) through a USB connection.
I have several other programs that connect fine to the printer.

I attempted to connect to it with the following commands:
set the serialControlString to "BAUD=115200 PARITY=N DATA=8 STOP=1 to=on xon=off odsr=off octs=off dtr=off rts=off isdr=off"
open driver "/dev/tty.usbmodem207F376659521" for text update

This open command (with different COM address), works with a Windows PC.

However, on the Mac, it delays a few seconds, then up comes the spinning beachball. It is stuck forever and the only way to recover control is to unplug the USB cable from the printer.

I must be missing something that the Mac version of LC needs that is different than the PC version.

EDIT: Got it to connect. I changed the device address to:
"/dev/cu.usbmodem207F376659521"

EDIT2: On a second 3D printer, it did not appear to connect even with the /cu variant. It did actually open the device, but it turns out that the virtual serial DTR line is not being set according to the LC serialControlString setting for the MacOS version. I am looking for a way to set this from LC to update the serialControlString and send it to an already open device.

I'm kind of surprised it works on windows, since LC doesn't yet have USB support officially. Apparently Windows is more flexible with its com ports.

LC had a poll some years ago about what features we would most like to see and I voted for USB but it didn't win.

jacque wrote: ↑

Thu Feb 07, 2019 5:12 pm

I'm kind of surprised it works on windows, since LC doesn't yet have USB support officially.

I am surprised by your response. The open driver command in the language dictionary states: "Use the open driver command to communicate with USB devices, devices attached to a serial port other than the modem and printer port, and other peripheral devices."

That looks like official USB support to me!

Perhaps this part of it?

Note: On Unix systems, devices can be addressed as part of the file system. This means that on such systems, the following two statements are equivalent:

Tip: Because OS X is based on Unix, you can use the open file command, as mentioned above, as a replacement for open driver on OS X systems.

*Note, i'm not anywhere near an osx system at the moment, so have no way to test.

see3d wrote: ↑

Thu Feb 07, 2019 5:26 pm

That looks like official USB support to me!

Yeah, could be now, my info is getting old. I think Craig might know more, he works with connected peripherals. I'd try the "file" approach next, I think.

bogs wrote: ↑

Thu Feb 07, 2019 5:42 pm

Perhaps this part of it?
"Tip: Because OS X is based on Unix, you can use the open file command, as mentioned above, as a replacement for open driver on OS X systems."

Yes, I noticed that also. I tried both open driver and open file. They behave identically. I would have hoped that there would have been some sort of timeout or error message to get a hint of the problem, but it just hangs forever until the USB cable is unplugged. Using a non-existent device address does not result in a hang.
The only thing I can think of is it may be a permissions issue. I have not been able to pinpoint that and other programs don't have a problem connecting --unless it is an actual bug in LC (I hope not).

Would be hard for me to say, as Jacque mentions, there are others far more involved with USB than I (I having no involvement).

Got it to connect. I changed the device address to:
"/dev/cu.usbmodem207F376659521"
So a JavaScript program needed the /dev/tty... to connect and MacOS needed the /dev/cu... to connect. And don't get them mixed up or you are going nowhere!

see3d wrote: ↑

Fri Feb 08, 2019 4:04 am

Got it to connect. I changed the device address to:
"/dev/cu.usbmodem207F376659521"

Hi,

I think here is an explanation (at least for me):

The idea is to supplement software in sharing a line between incoming and outgoing calls. The callin device (typically /dev/tty*) is used for incoming traffic. Any process trying to open it blocks within the open() call as long as DCD is not asserted by hardware (i.e. as long as the modem doesn't have a carrier). During this, the callout device (typically /dev/cu* -- cu stands for "calling unit") can be freely used. Opening /dev/cu* doesn't require DCD to be asserted and succeeds immediately. Once succeeded, the blocked open() on the callin device will be suspended, and cannot even complete when DCD is raised, until the cu device is closed again.

That way, you can have a getty listening on /dev/tty*, and can still use /dev/cu* without restrictions.

PS: shamelessly copy-paste from somewhere...

Thierry wrote: ↑

Fri Feb 08, 2019 8:44 am

I think here is an explanation (at least for me)

Thank you. This is very helpful towards understanding the root cause of my difficulty. A holdover from an era long past.

Even though I got it to connect with the /dev/cu.usbmodem address, I could only write, but not read anything from another 3D printer. I found the root cause of why: Setting the serialControlString with dtr=on does not result in the dtr line being on. The default state is off and it stays off no matter what. While many other languages allow changing the state of these (virtual) lines, I can not find a way to do it in LC. The 3D printer will accept commands sent to it after it is open, and will send responses. It is just that the LC read from driver command ignores inputs unless the dtr state is asserted.

I can connect with LC, then make another connection with a terminal app that lets me change the dtr state, then disconnect. After that LC can fully communicate to the printer.

Is there a workaround in LC to control the dtr state after the open connection is made?

see3d wrote: ↑

Wed Feb 27, 2019 4:16 am

I can connect with LC, then make another connection with a terminal app that lets me change the dtr state, then disconnect. After that LC can fully communicate to the printer.

Well, why not use shell(dictionary) to execute the cli and then connect to it? Alternately, if you have to connect to it with Lc first (not sure why), do that then use shell for the cli then disconnect/reconnect.

bogs wrote: ↑

Wed Feb 27, 2019 11:51 am

Well, why not use shell(dictionary) to execute the cli and then connect to it? Alternately, if you have to connect to it with Lc first (not sure why), do that then use shell for the cli then disconnect/reconnect.

I would love to use shell. I tried it for a day. Internet showed others could not get CLI to work either. There was no command that would work any better and no way I could find to toggle the DTR line. It seems this is a "feature" of MacOS, and many posts about it over the years. Mac Terminal app can connect to my printer and handles the DTR correctly, but it wants to own the device exclusively and won't make a 2nd connection if LC has already connected. If I were proficient at C programming, perhaps I could make an LC extension.

Hmm, I don't know if you saw this comment (old dictionary) -

francois.chaplais@mines-paristech.fr 2009-09-01 at 08:55:22 wrote:Mac OS X note: the environment variables which are available in the shell function may not be the same as those available in the Terminal app. For instance, it may be necessary to update the $PATH variable to make some commands available to the shell function.

since LC doesn't yet have USB support officially

Cripes, that's a real case of lagging behind.