LB Booster: Serial com in LBB/LB4

LB Booster
Programming >> Liberty BASIC language >> Serial com in LBB/LB4 - what is different?
http://lbb.conforums.com/index.cgi?board=lblang&action=display&num=1398366144

Serial com in LBB/LB4 - what is different?
Post by flotulopex on Apr 24^th, 2014, 7:02pm

Hi,

I'm trying to send simple G-code commands to my 3D printer via a simple LBB program but the printer won't execute the command.

BUT when I use a serial com software (HyperTerminal like), it does work.

As an example, I send this command in the serial com software: G1 X100 Y100 Z100 and <CR> as terminator; this will position the printer's head somewhere I want it to be.

Via LBB, I tried these two small pieces of code; none of them will work:

Code:

OPEN "COM3:115200,n,8,1" FOR RANDOM AS #PRINTER
#PRINTER "G1 X100 Y100 Z100" + CHR$(13)
CLOSE #PRINTER
END

Code:

OPEN "COM3:115200,n,8,1" FOR RANDOM AS #PRINTER

timer 2000, [done]
wait
[done]
timer 0

#PRINTER "G1 X100 Y100 Z100" + CHR$(13)
CLOSE #PRINTER
END

There is obviously a difference between both system used to transmit serial data.

Any idea what it is?

Roger

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on Apr 24^th, 2014, 8:27pm

on Apr 24^th, 2014, 7:02pm, flotulopex wrote:

There is obviously a difference between both system used to transmit serial data. Any idea what it is?

I think you've failed to take account of this comment in the Compatibility section of the LBB docs:

"12. Opening a file in BINARY mode does not prevent PRINT outputting a newline (CRLF). To suppress the newline add a trailing semicolon (;) to the PRINT statement; this will not affect the operation of the program in LB4."

So your code:

Code:

#PRINTER "G1 X100 Y100 Z100" + CHR$(13)

Will output the string followed by the sequence CR CR LF, which is probably not what you intended. Try adding a terminating semicolon:

Code:

#PRINTER "G1 X100 Y100 Z100" + CHR$(13);

That may be all you need to make it work. As the LBB docs note, adding the semicolon does not affect compatibility with LB.

LBB cannot emulate LB's (rather peculiar) feature of suppressing the CRLF when the file (or port) is opened in BINARY mode because there is no way it can determine at run-time (i.e. solely from the handle) what mode was specified.

Richard.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on Apr 25^th, 2014, 10:26am

on Apr 24^th, 2014, 8:27pm, Richard Russell wrote:

....I think you've failed to take account of this comment in the Compatibility section of the LBB docs...

No, in fact I did use a semi-colon for some tests but I wrongly wrote my code like this (=semi-colon after the command text):
Code:

#PRINTER "G1 X100 Y100 Z100"; + CHR$(13

I'll try this tonight ;-)

Meanwhile, you may have an idea how I can make the terminators caracters "visible" in an serial com software or is it simply "not possible"?

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on Apr 25^th, 2014, 1:11pm

on Apr 25^th, 2014, 10:26am, flotulopex wrote:

Meanwhile, you may have an idea how I can make the terminators caracters "visible" in an serial com software

In LBB characters with codes less than 32 (i.e. 'control characters') will never be visible when printed to the mainwin, since those codes have special meanings. To make the characters 'visible' you would need to convert them into something different; that can easily be done but may be rather slow. The code listed below (LBB-specific) displays the control characters in red.

Richard.

Code:

string$ = "G1 X100 Y100 Z100" + CHR$(13) + CHR$(10)
print visible$(string$)
end

function visible$(s$)
for i = 1 to len(s$)
  c = asc(mid$(s$,i))
  if c < 32 then
    visible$ = visible$ + chr$(17)+chr$(1)+chr$(64+c)+chr$(17)+chr$(0)
  else
    visible$ = visible$ + chr$(c)
  end if
next
end function

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on Apr 25^th, 2014, 4:27pm

Well...still not working either ways.

I need to trap what serial data I'm sending to the printer via LBB or the com software.

Any idea how to do so?

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on Apr 25^th, 2014, 4:42pm

Just found a serial com capturing tool http://www.eltima.com/products/rs232-data-logger/

I'll have a go and see what happens wink

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on Apr 25^th, 2014, 5:21pm

How can I modify/set the serial data flow control type in LBB (Xon/Xoff - Hardware - None)?

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on Apr 25^th, 2014, 5:33pm

The syntax for serial port parameters is slightly different. The basic options are the same, so for example this works:

open "COM1:9600,n,8,1" for random as #comm

but when specifying 'handshaking' parameters the syntax accepted by LBB is as follows:

open "COMn: [baud=b] [parity=p] [data=d] [stop=s]
[to=on|off] [xon=on|off] [odsr=on|off] [octs=on|off]
[dtr=on|off|hs] [rts=on|off|hs|tg] [idsr=on|off]"

I don't get it.

What would the correct syntax be in my case please?

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on Apr 25^th, 2014, 9:55pm

on Apr 25^th, 2014, 4:27pm, flotulopex wrote:

How can I modify/set the serial data flow control type in LBB (Xon/Xoff - Hardware - None)?

Code:

OPEN "COM3: baud=115200 parity=n data=8 stop=1 xon=on odsr=off octs=off" FOR RANDOM AS #PRINTER

However I'm not sure whether Xon/Xoff handshaking is always available in Windows; it may depend on your serial port driver. Personally I would prefer to implement it in my own code because that way you know it will always work.

Richard.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on Apr 26^th, 2014, 12:49pm

cry

Still won't work.

Since the beginning of this thread, when I send the data to the printer , I can see on its LCD some kind of "reset" since it will show up the "start screen" just as when I switch it on. That means, all changes I made to the data sent as in my first post don't modify anything.

If there is no difference in the data itself, no obvious flow control issue, what is still to be investigated?

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on Apr 26^th, 2014, 5:04pm

on Apr 26^th, 2014, 12:49pm, flotulopex wrote:

If there is no difference in the data itself, no obvious flow control issue, what is still to be investigated?

You say the data is correct, but what about the baud rate, parity bit (if any) and number of stop bits? If any of those are wrong it is entirely likely that the receiving device will not respond correctly. An oscilloscope is an invaluable tool to investigate those issues.

There are not that many ways in which the serial signal could be wrong, so if you have appropriate monitoring facilities it should be relatively simple to debug the problem. You are far better placed to do that than I am!

Richard.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on Apr 28^th, 2014, 10:01am

...yup!

The oscillo is on my table already but I can't still point the problem.

I'll check some more....

Re: Serial com in LBB/LB4 - what is different?
Post by Rod on Apr 28^th, 2014, 3:25pm

If you say that you can issue the commands via HyperTerminal like software then it can be achieved with LBB.

Couple of guesses, COM3 does not sound right. If you are using a USB based serial module its likely to be a higher number.

Use the Control Panel to double check what Com number and parameters the HyperTerminal like software is using.

Are you sure it just terminates with a CR? Some of these modules use a check digit routine appending a character to the end of the message.

Is the printer home made? who makes the HyperTerminal like software and can you post a link to their support pages?

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on Apr 30^th, 2014, 05:50am

Thanks Rod,

I checked these points already: COM ports, speed and other parameters all are fine.

The com tool lets me choose between different terminators; I just needed to test them one by one to find the correct one, the only one that works is "CR".

The printer is this one http://www.bqreaders.com/gb/products/witbox.html.

I use the "Serial Communicator" software utility coming with this editor http://www.mecanique.co.uk/shop/index.php?route=product/category&path=20_62.

Until now, I sniffed the com port with this tool http://www.eltima.com/products/serial-port-monitor/. But it doesn't shows up any kind of special control er checking character.

I need to look into the transmitted data packet with my oscillo and maybe find if there is a difference.

But I don't have any protocol analyzing tool so if there is a difference, I'll still need to find out what exactly it is.

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on Apr 30^th, 2014, 08:33am

on Apr 30^th, 2014, 05:50am, flotulopex wrote:

The com tool lets me choose between different terminators; I just needed to test them one by one to find the correct one, the only one that works is "CR".

Evidently you don't have a detailed specification of the data format accepted by the printer, otherwise you would not have needed to perform that experiment. Can you not obtain such a specification from the printer manufacturer?

Richard.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on Apr 30^th, 2014, 08:40am

I did open a ticket at their support center.

Wait and see wink

Re: Serial com in LBB/LB4 - what is different?
Post by Rod on Apr 30^th, 2014, 10:34am

Having had a browse and I search I find very little on line help or discussion. Everyone seems to use the bundled software.

What I do see is that the software uses parameter files which would suggest that you just cant start printing to the printer you have to give it the setup info first.

I also see that DTR is part of the serial setup so you will need to take note of that. It seems to be used to force a reset. So it is one handshaking line that you may need to manage.

I don't understand why you are using this microprocessor serial tool. I would have thought that you just open the g code file in LBB and print it to the serial com port.

When you look at how the working software works, look at how it opens the port, what it does with the handshaking lines and what preliminary data it sends to the printer.

Of course proper technical help or documentation would ease the journey.

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on Apr 30^th, 2014, 1:46pm

on Apr 30^th, 2014, 10:34am, Rod wrote:

I also see that DTR is part of the serial setup so you will need to take note of that. It seems to be used to force a reset. So it is one handshaking line that you may need to manage.

You can initialise the DTR line when the port is opened; for example to set it 'on':

Code:

    OPEN "COM3: baud=115200 parity=n data=8 stop=1 dtr=on" FOR RANDOM AS #PRINTER

If you need to control DTR 'actively', after the port has been opened, LBB makes that easy because it exposes the native file handle via the HWND() function. For example to set DTR:

Code:

    handle = hwnd(#PRINTER)
    calldll #kernel32, "EscapeCommFunction", handle as ulong, _SETDTR as long, r as long

Richard.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on May 1^st, 2014, 7:18pm

My printer is normally connected directly to my PC via an USB cable. In the printer, there is a FTDI USB to RS232 converter.

Unfortunately, I can't reach the RS232's RX pin on the printer's board (it is inaccessible).

As I have a FTDI USB-RS232 cable http://www.ftdichip.com/Products/Cables/USBRS232.htm, I have connected my probe directly on the TX pin of this cable and this is what I can see.

Message sent is (without quotes) "G28".

Leaving/changing/removing any termination character (with Serial Communicator) will not change anything to the "Serial Com sent data" image and that confuses me.

LBB sent data

User Image

Serial Com sent data

User Image

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on May 1^st, 2014, 8:53pm

on May 1^st, 2014, 7:18pm, flotulopex wrote:

I have connected my probe directly on the TX pin of this cable and this is what I can see.

Why are there such large gaps between the characters; is this the effect of the Xon/Xoff handshaking? With both data sources the "G28" message appears to be taking something in excess of 2 milliseconds, rather than the 0.26 ms which would be expected at 115,200 baud (three characters, each consisting of 1 start bit, 8 data bits and 1 stop bit: 30 bits in all).

Here is "G28" in serial bits, which ties up with what your waveforms show:

0111000101 0010011001 0000111001

Richard.

Re: Serial com in LBB/LB4 - what is different?
Post by Rod on May 2^nd, 2014, 7:26pm

Ok, we are making this far too complex. serial coms is simple. You send characters and they are received, forget flow control and ditch the oscilloscope.

Plug in your printer, open your control panel and check what com port the printer establishes itself as.

Tell us what that is. Use Port Monitor to record that com ports activity. Establish what happens from the moment you plug in the printer's USB lead to invoking the printer utility software.

It may be that a stream of setup code is sent prior to the printer handling the "g" code. It may be that the DTR handshaking line is set at a specific value.

There is no point in examining the bits, bits are bits, clearly the printer isn't listening for other reasons. So Port Monitor will show you exactly how the port is established and exactly what data is sent. If you can record this it can be replicated with LBB.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on May 3^rd, 2014, 3:11pm

Right, so here we are.

Recorded logs can be found here: http://home.citycable.ch/flotulopex/divers/3D-Serial_Com_Logs/.

The "Console View" via LBB is an empty file (as logged by the PORT MONITOR software found here: http://www.serial-port-monitor.com/index.html ).

As I sent "G28" from the "Serial Communicator" software, the code used on LBB's side is this one:
Code:

ComPort$ = "3"
BaudRate = 115200
Parity$ = "n"
DataBits = 8
StopBits = 1

OPEN "COM";ComPort$;":";BaudRate;",";Parity$;",";DataBits;",";StopBits FOR RANDOM AS #PRINTER

TIMER 5000, [DONE]
WAIT
[DONE]
TIMER 0

#PRINTER "G28";

CLOSE #PRINTER
END

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on May 3^rd, 2014, 3:17pm

on May 2^nd, 2014, 7:26pm, Rod wrote:

It may be that a stream of setup code is sent prior to the printer handling the "g" code. It may be that the DTR handshaking line is set at a specific value.

I think you may have pointed the problem.

How can I make LBB "wait" for an incoming message from the 3D-printer just like it appears in the Serial Communicator program?

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on May 3^rd, 2014, 4:30pm

on May 3^rd, 2014, 3:17pm, flotulopex wrote:

How can I make LBB "wait" for an incoming message from the 3D-printer just like it appears in the Serial Communicator program?

Although that is easy, in my opinion it is not the right way to go about things.

Attempting to 'reverse engineer' the printer's communication protocols, by monitoring what the 'official' software does, is unlikely to be satisfactory. Even if you could make it work, it would probably not be reliable. Although you can see what happens in a specific set of circumstances, you can never discover what you need to do if the circumstances are different.

Rather, you should find out what the official protocols are for driving the printer and write a program which implements them. If the manufacturer does not publish those protocols you should probably not be attempting to drive it directly.

This is not a forum for helping hackers! Sorry.

Richard.

Re: Serial com in LBB/LB4 - what is different?
Post by Rod on May 3^rd, 2014, 5:24pm

Agreed.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on May 3^rd, 2014, 6:21pm

huh

I'm not trying to "reverse engineering" anything; I want to USE tools I have bought or paid for to create something useful with all respect to anybody's intellectual rights.

Maybe I have come to a point where there is no "simple" solution to what I'm asking.

Re: Serial com in LBB/LB4 - what is different?
Post by Rod on May 4^th, 2014, 09:00am

Solutions come from having an understanding of the problem. I don't have that yet.

You have purchased an expensive printer. It comes with a variety of open source software that works.

It can use a memory card to print gcode files, it can use the serial port to print gcode files.

My first assumption is that you know how to write useable gcode files.

So step one would be to write the file to a memory card and print from there.

Step two would be to use the helper software, load your gcode file to it and print via the serial link to the printer.

My second assumption is that both these processes have been catered for by the printer manufacturer and work.

So, now you want to connect the printer directly to LBB and bypass all of the helper software and drive the printer directly? Is that the task in hand? If so what do you gain over the previous two printing methods that work? I am trying to understand the problem better.

If you are not trying to take direct control of the printer with LBB can you please explain a little more, what is the exact task in hand?

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on May 4^th, 2014, 7:34pm

The are several tools one can find in the internet to make, for example, the 3D printer positioning the extruder somewhere you want it to have at the end of the printing process (for cleaning purposes). You may also want to switch off some fans or so.

Currently, I can achieve this by sending g-code commands via almost any serial communication software.

I wasn't able to do so with LBB until a few hours ago.

But one of you said that if a serial com software can "talk" to my printer, LBB would be able to do it too.

So "yes, it does it.

All I needed was to:
- open the COM port
- wait around 10 seconds (= I need to wait for the printer to end his start-up procedure and listen to incoming commands)
- send the command.

So thanks to all of you for the help....and yes, the solution was rather simple wink

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on May 4^th, 2014, 8:32pm

on May 4^th, 2014, 7:34pm, flotulopex wrote:

Currently, I can achieve this by sending g-code commands via almost any serial communication software...
I wasn't able to do so with LBB until a few hours ago.... All I needed was to... wait around 10 seconds

Sorry, I still don't properly understand. Are you saying that when sending data from "any serial communication software" it is not necessary to wait ten seconds, but when sending from LBB it is necessary to wait?

Richard.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on May 4^th, 2014, 9:20pm

When the COM port is opened by LBB or any other com software, the printer sends out several data to the PC. This takes a few seconds (a little less than ten seconds).

During this time, no commands can be sent to the printer - the printer is not "listening" to any incoming command.

Since I always had to type in the g-code command in the serial com software, this took a few seconds giving the time to the printer to be able to "receive" my command.

Unfortunately, when I was using my LBB program, things went much faster not allowing enough time for the printer to be "receive" ready and acknowledge the command.

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on May 5^th, 2014, 08:33am

on May 4^th, 2014, 9:20pm, flotulopex wrote:

Unfortunately, when I was using my LBB program, things went much faster not allowing enough time for the printer to be "receive" ready and acknowledge the command.

OK, that makes sense; thanks for the explanation.

However, something still puzzles me. The subject line for this thread is "Serial com in LBB/LB4 - what is different?" which clearly implies that your problem was related to some incompatibility between LB4 and LBB. Indeed, the early exchanges in the thread were about known differences: the need to add a trailing semicolon in LBB, even if the port is opened as BINARY, and the different syntax used to control the handshaking options.

But, surely, LB 4.04 starts sending data as soon as the port is opened, just like LBB does, so why was the need to wait ten seconds not identified before you ported the code to LBB? If the code ran in LB4 without the delay, how?

Richard.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on May 5^th, 2014, 09:22am

Quote:

...so why was the need to wait ten seconds not identified before you ported the code to LBB?

Sorry, I don't understand your question.

Or do you mean: why did Roger add ten seconds wait time in the LBB code since it worked in LB4 without that waiting period?

Did I say it worked in LB4 previously? To be honest, I didn't even try under LB4.... lipsrsealed

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on May 5^th, 2014, 10:07am

on May 5^th, 2014, 09:22am, flotulopex wrote:

Did I say it worked in LB4 previously? To be honest, I didn't even try under LB4.... lipsrsealed

I read your subject line "Serial com in LBB/LB4 - what is different?" as asking about differences between LBB and LB4. Was I wrong? Why did you mention LB4 at all if you didn't even try it?

Richard.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on May 5^th, 2014, 1:47pm

Subject should have been called: Serial com via LBB/LB4 or Terminal Software - what is different? But this is far too long....

Re: Serial com in LBB/LB4 - what is different?
Post by Rod on May 5^th, 2014, 1:51pm

If you are not used to serial comms the first lesson to learn is timing, buffers fill up, printers chunter and the PC flys along at a speed the port can't hope to follow.

http://lbpe.wikispaces.com/AccessingSerialPort

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on May 5^th, 2014, 3:52pm

Thanks Rod,

This is exactly where I started.

Re: Serial com in LBB/LB4 - what is different?
Post by net2014 on May 5^th, 2014, 6:36pm

on May 5^th, 2014, 1:51pm, Rod wrote:

If you are not used to serial comms the first lesson to learn is timing, buffers fill up, printers chunter and the PC flys along at a speed the port can't hope to follow.

http://lbpe.wikispaces.com/AccessingSerialPort

I have to admit my use of serial comms usually involves some fudge of timing to make things work, but in reality shouldn't timing be irrelevant? That's why handshake lines are part of rs232 specification. These lines seem to be disabled in LB4 serial open command. Isn't LB4/LBB able to handle handshaking? If it is capable then perhaps we should put some effort into proper handshake investigation.

Re: Serial com in LBB/LB4 - what is different?
Post by Richard Russell on May 5^th, 2014, 8:29pm

on May 5^th, 2014, 6:36pm, net2014 wrote:

I have to admit my use of serial comms usually involves some fudge of timing to make things work, but in reality shouldn't timing be irrelevant?

It's honest of you to admit it, but as you say it shouldn't be necessary.

Quote:

That's why handshake lines are part of rs232 specification.

Not really. You commonly don't need any explicit handshaking or timing fudges.

For example if the communication protocol involves data packets alternately flowing in one direction and then the other (poll-data-poll-data or data-response-data-response) then the only requirement is that the receive buffer is big enough to hold an entire packet.

Even if the communication is one-way you still don't need any handshaking if these conditions are met:

The average rate at which the receiving end can accept and process data exceeds the average transmission rate.
There is a receive buffer of sufficient length that it can cope with the worst case fluctuation of transmit rate and receive processing capability.

With typical baud rates and processing speeds these conditions can often be easily met.

Since the majority of applications match one or other of these cases, handshaking is rarely necessary. That is fortunate given that many communication paths do not support the additional data channels that are necessary for hardware handshaking.

Quote:

Isn't LB4/LBB able to handle handshaking? If it is capable then perhaps we should put some effort into proper handshake investigation.

Of course they can handle handshaking, but I don't really agree that much investigation is desirable given how unusual it is for it to be needed.

Richard.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on May 6^th, 2014, 1:11pm

This was my question to the printer's support service:
Quote:

Hello,
I'm trying to send G-code commands to my Witbox via my PC.
It works via HyperTerminal but it will not work with other programming languages I use and I can't find what is wrong.
May I kindly ask you to give me the serial data protocol you use (baud, parity, data ,stop, flow control and so on)?
Is there any CRC or special controlling character used?
Thank you for your help.
Roger

...here's the answer I got:
Quote:

Dear Roger,
In Witbox, it is baud to 115200. You may know serial port to comunnicate with it.
You may use PuTTy, it is software for comunnicate with Witbox.
We remain at your disposal for any questions
Saludos,

Re: Serial com in LBB/LB4 - what is different?
Post by Rod on May 9^th, 2014, 5:44pm

Having browsed a bit deeper I see that we are asking the wrong questions. The serial link is the serial link and it works and isn't the problem.

The Witbox uses an open source electronics board to drive its stepper motors and extruder. Ramps 1.4. This is an Arduino based microprocessor board that manages all aspects of 3d printing. It is used in a variety of modern 3d printers.

So if you want to take control of the printer you need to research Ramps 1.4

Will this be easy? Well it's kinda like asking me to take my All in One printer scanner, take control of the scanner, move it to 100,100 and scan the next three pixels. Easy? No way.

But I have not researched Ramps 1.4 protocol, that's where you need to spend the time.

Witbox clearly focus on the hardware, which they appear to be superb at. But they have opted for the open source driver software, so you will get bland responses if you query comms when the real focus should be Ramps.

Re: Serial com in LBB/LB4 - what is different?
Post by flotulopex on May 12^th, 2014, 12:19pm

Thanks Rod,

That's effectively THE board (Ramp)!

As you say, the problem is (was) not either on a serial comm level nor on LBB's side, but one has to start somewhere one time and the info I got back in this forum helped me to find the solution, even the one I didn't expect.