 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : COM ports vs SerialTx CSub....
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
Hi there.  I am trying to send data to a thermal printer using the SerialTx CSub. It will not work. I don't know why. If I move the wire from the printer, to COM1 rather then pin-7 that I wanted to use with SerialTx, open COM1 at 19k2 and send data to the printer - it prints just fine. Put the printer wire back on pin-7, send the same data using SerialTx 7,19200,D$ - the printer ignores it. Perhaps I need to also use the ChangePin Cfunction? If I connect the VT100 ASCII Terminal to pin-7 and send the data, the terminal shows the correct output. This is odd.....  Does anyone have any ideas? Smoke makes things work. When the smoke gets out, it stops! |
||||
CaptainBoing Guru  Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
Morning Grogs. I have never had a problem using the serial TX routine. I have only ever done stuff at 9600 and have pretty much standardised everything at that. Have you tried dropping the speed? Here's my work on it if it helps http://www.fruitoftheshed.com/MMBasic.LPrint-for-attached-serial-printer-legacy-BASIC-statement.ashx I must say, the thermal printer I use is a hungry little swine and the PSU must be up to scratch, although I doubt this is pertinent in your case http://www.fruitoftheshed.com/Platform%20Agnostic.Simple-and-Cheap-way-to-add-a-Printer-to-your-project.ashx I find the SerialTx CSub works just fine. Have you used the pin for something else before hand? Needs to be an output but if I remember, SerialTx takes care of all that. Curious about why you thought of ChangePin. Have you scoped the pin? Remember that you can get weird crashes in the firmware so consider re-flashing/different chip when you get crazy stuff like this. What printer are you using? Can't see why that would impact working on one pin and not the other but just asking. regards Edited 2019-09-30 18:29 by CaptainBoing |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
Very odd indeed. Perhaps your printer is very sensitive to timing variations - the CSub is not perfect in that regard. You might get a clue by using a logic analyser to compare the CSub and COM1 output. Geoff Graham - http://geoffg.net |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
@ CaptainBoing: I used to have a utility to setup these printers, but I cannot find it now, despite much searching. That means the unit is stuck at 19k2 and I can't really change it - unless I find that utility. Yes, I have a nice juicy 3A PSU feeding the printer itself, so no problems there. You are correct - they are thirsty when they are printing!  I thought of the ChangePin CFunction, as I needed to use that once before with a SIM7600 SMS module, or the MM would flatly refuse to see any response from the module. I disabled the internal pull-up with the function. Module had its own pull-up. I was wondering if I could do something similar here.@ Geoff: I will capture the output from both and compare. I will post images here for others interest. It's damn strange, as I use both the SerialTx and the SerialRx CSub's in many projects now, and they have never let me down. Just in case others reading this are wondering: 'Why don't you just use COM1 or COM2 then?' - I have already assigned them to something else. I guess I could re-work my pinout if I had to, but that would mean a new PCB layout, but that would not be the end of the world I suppose.... I will now sample the outputs of both on the logic analyser, and upload the files here. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
SOLVED!  The logic analyser shows that the COM port automatically adds a CR and LF to the end of the data, and that makes all the difference. My D$ I was sending via the SerialTx CSub does NOT add those two extra bytes at the end, and so the printer never prints, as it is obviously waiting on the CR or LF or both - and it never gets them via the CSub! This is completely my fault, and something I should have thought of really....  As that is all that was stopping it, I won't bother to post the logic data or GIF images. But as soon as I saw that the COM port adds those two bytes, I had a 'Lightbulb' moment, and I manually added a CR and LF to D$, and now the SerialTx CSub works fine with the printer. Onward and upwards.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
hah! see my LPrint Wiki! Well done Grogs!  I use the SerialTx instead of a pukka COM port as I really can't stomach the idea of wasting a whole port for the sake of one wire. Even when I have a "spare" COM port, I'll still task some vacant pin for the serial printer. Stuff like that would keep me awake  Edited 2019-10-01 06:29 by CaptainBoing |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
I love the built-in serial port buffer that you get with the COM ports though. That allows the serial port to receive data in the background, and then your main loop can just deal with whatever it might find in there as part of the main loop. That way, you don't have to sit there waiting for data, if you don't know when data may arrive. SerialTx and SerialRx are fantastic for general purpose serial work, and effectively do the same thing as the PICAXE SEROUT and SERIN commands. Smoke makes things work. When the smoke gets out, it stops! |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
yes, SerialRx has some caveats in operation... but I don't think I have ever used it. I imagine (due to its bit-bashing nature) that SerialTx is blocking, i.e. everything stops until it is finished. Easily tested by elapsed time with a small string and then with a big string. Grogs; seeing as you are already set up and playing with this stuff would you care to test for that? Cheeky, I know, but that is part of my enduring charm cheers h |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
I can save Grogs the effort... SerialTx is blocking. Geoff Graham - http://geoffg.net |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
It is....BUT....you can specify a timeout - that is the next best thing. r = SerialRx( pin, baud-rate, string$, timeout, maxchars, termchars) So, for example: R=SerialRx(7,2400,D$,1500) ...will return with whatever was received after 1.5 seconds. This is still VERY useful. The PICAXE excel in SINGLE-TASK operation with this. You specify a SERIN qualifier, and the PICAXE will sit there forever waiting on the quaklifier. It will only continue to process code IF it gets that serial qualifier. But that is the PICAXE. Excellent for single-tasking stuff like that. @ Geoff: Are you aware that the SerialRx.pdf included in the distro, says "SerialTx" in the examples? ...end of page one. I am basing that on the 5.05.01 release. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
Dammit...... Sorry, folks. To much wine tonight. I see you are talking about SerialTx and not SerialRx. Yes, SerialTx will NOT return till it has sent all the data. At high baud-rates, that is not a problem. I could delete the above post, but then.....members would not have the chance to laugh at me for my wine intake.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
 Wine. Educator, enlightener, comforter, ridiculer.Thanks Geoff. Blocking is not generally a problem if thoughtfully accommodated in single-threaded micro-controller applications. Rule of thumb; keep it fast or keep it small. Edited 2019-10-01 19:59 by CaptainBoing |
||||
| BrianP Senior Member  Joined: 30/03/2017 Location: AustraliaPosts: 292 |
Or maybe keep it dry?? |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Grogs ... I see that you're quickly becoming a Linux guru! Wine, (a recursive backronym for "Wine Is Not an Emulator"), is a free and open-source compatibility layer that aims to allow computer programs developed for Microsoft Windows to run on Unix-like operating systems.  Paul in NY. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
