Channel or function not found.... (?)


Recommended Posts


I have created new serial device and pointed to COM1 and name it Com_Port. I have succesfully created new protocol according to serial guide and no problem receiving data from Com1.

But when I try to send data with write() function with following sintax:


system return error C1000 Channel or function not found.... BUT data are sended to com1 and appear on my virtual machine (Proteus ISIS) and Comm monitor too (TX: TEST), as you can on my print screen.

How to send data without this error? Do I have do it throw channel?

Thank you.


Link to comment
Share on other sites

Did you name your com port "Com_Port" or did you name your device "Com_Port". The com port and protocol names in the comm device are only used in the selection window and never in script. All script should always reference the device name. Also, if you are doing it from within a user protocol, you just do write() without device.mydevice. because you are inside the device already. If you fully specify it as device.mydevice.write() then you won't be able to use the protocol on any other device names you may create in the future (unless you named it mydevice as well).

Link to comment
Share on other sites

Which protocol do you have selected?

Ok. I folowed your manual.

I do this:

1. Quck - Device configuration - New Serial (RS232/468)....

2. Device name: Com_Port

3. New Serial : Connection name COM1 (Serial port # 1 ... bla bla)

4. New protokol, name GET_PUT_COM_PORT (same file name+ddp in DAQFactory folder)

5. On receive event code (as in manual):

if (strIn == chr(13)) // we've received the EOL character 
  private string DataIn = ReadUntil(13)

Receive from com1 work. I create channel as described in manual. Receive work! No problem!

"...did you put any code in the OnSend function?"

"On Send" is triggered after actual sending to com port. It's irrelevant to my problem.

You might try selecting the NULL protocol

No. Why should I?

In fact I do as you described in manual, why should I change to NULL now? This is quite enough for me now. Maybe you can add in manual how to send data, after you describe how to receive?

Now I only need how to send data with created device (Com_Port), from sequence or from screen component (eg. button action "Quick sequence").

How? And without error which was my first question.

Link to comment
Share on other sites

I did not know what your protocol was doing and that you were using OnReceive. I recommended switching to NULL, just temporarily, to simplify the system. If it fixes the problem, then something is wrong in your protocol.

There is no reason this line won't work:


What release of DAQFactory are you running? Maybe you can post your .ctl doc (or email it direct if you don't want to post it) so I can see if there is something else going on.

Link to comment
Share on other sites

Yes no problem.

I make new and very small application. I create new serial device (as I described in previous post) and use NULL protocol as you suggested. And I didn't make any sequence for receive or sending.

And now one very nasty bug.

When ever I send chr(13), program put in receive buffer chr(13) and chr(10).

Example: With this sequences:

device.Com_port.Write(" Button 1")

Comm monitor show this:

Tx: Button 113

Rx: 1310

With this sequences:

device.Com_port.Write("Button 2 without chr(13)")

I really plan to buy this program, but this is very frustrating at the very beginning....

Comm monitor show this:

Tx: Button 2 without chr(13)

And when I send ONLY characte 13 with


Comm monitor show this:

Tx: 13

Rx: 1310

This clearly show that any chr(13) in transmit bytes sequence trigger "receiving ghosts" chr(13) and chr(10).

I send you .ctl application. DaqFactory version is

ProRelease 5.79A Build 1575 - Trial version

(with patch for Croatian characters from another post)

OS: Windows XP with SP2 on WMvare Workstation

I really plan to buy this products, but this behavior is very frustrating at the very beginning. This eating my trial period which I was plan to make something usefully for learning DaqFactory. (I want my time back B))


Link to comment
Share on other sites

First, I'm assuming the monitor window actually looks more like this:

Tx: Button 113

Rx: 1310

Next, this is actually not a bug, but instead is what your device is returning. DAQFactory is transmitting only a carriage return (the single 13), but the device is returning both a carriage return / line feed pair. I don't know your device, so can't address the problem, but I assure you that it is not a bug, but in fact unexpected behavior from your device.

As for your trial, if you need an extension, please email us directly and we can extend your trial.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.