Trying to communication with DCS Simulator through terminal

[Art]

Hello all,

I have downloaded and installed DCS Simulator and I’m trying to communicate with it through PuTTY terminal.
I successfully connected to the simulator and it receives the chars I’m typing but no matter what I’m typing I receive the message “Unexpected character <ascii code> received”.

I have tried to change the Translation settings of the terminal with different encoding types but it didn't matter.

Can you guide me what should I configure on my terminal to make the simulator understand me?

[Yaron [LaserOp]]

Hi Art,

There are a few issues. Both in what you're actually sending, and in that PuTTY isn't really an ideal tool here since the DCS protocol, while mostly textual, has specific control characters it of course doesn't handle automatically.

To start, looking at the communication log in your screenshot, you're starting your connection as a "Telnet" connection, which involves signaling that the simulator doesn't expect (because it isn't a Telnet server). So about the first 2/3 of the connection you're seeing is just PuTTY trying to initiate a Telnet connection, and the DCS simulator not understanding it. This one is the easiest problem, when you set the connection in PuTTY choose for the Connection Type the "Raw" option, and not Telnet.

This brings us to the second issue, the DCS control characters ("Reserved characters"). To start (sorry for the pun), the FS (Start of message) character is not actually a text string reading "<FS>" . That <xx> format is an indication code of a single control character (in this case hex code 0x1C, decimal 28).

So from the preview of the PuTTY window in your screenshot, it's supposed to be starting a new DCS message with a TRCFMT record, the decimal codes of the individual characters in sequence, if it was correct, would be 28 84 82 67 70 77 84 61 49 . The 28 is <FS> followed by the text (then followed in a real packet by 13 10 , which is <CR><LF> for End of Line).

Instead you're just tying "<FS>" as a string to PuTTY, so the DCS Simulator doesn't receive the <FS> character. If you'll look at the error log this is the sequence it doesn't recognize of 60 70 83 62. It just gets each of the individual characters. Which is wrong, these are, again, just the human-readable representation of the relevant control character.

So to use PuTTY, you'll need to be able to to send the control characters correctly.

If you have full/large data you want to enter, without having to type it manually, edit the file in advance to match (use a hex editor, or a text editor that allows to search&replace with individual non-textual character codes, do you need recommendations?). You can then copy from the file and paste into PuTTY. That should make it send the full correct sequence. Again, make sure to replace all the "readable" control character representation, with the actual key codes.

If you're fine with typing manually, all of these characters also have a way to send them directly with a Control Key combination (Ctrl + key). For example you can send the <FS> character on the PuTTY terminal by holding Ctrl and pressing the "\" key.

If you check the VCA DCS document, in Table 1 "Reserverd Characters" you can see a list of all of the needed characters, all with the readable text representation, the hex and decimal values, and the control key code.

For control keys, if you want to type in the terminal rather than copy from a file, notice that holding Ctrl in the table is represented with a "^" character prefix. So for <FS> in the table it says ^\ , which means hold Ctrl while pressing the "\" character. The exception is the <RS> key, shown as ^^, For Ctrl+^ , easiest on most keyboards by having Caps-Lock on and pressing Ctrl and "6" above the keyboard (not the keypad).

Also for end of line / record, just use ^J (<LF>, 10, 0x0A) , it will be enough for the DCS Simulator to separate records, and won't cause PuTTY to send an incomplete packet as it will do on CR/^M .

I hope this helps. Though to be honest, this is fine if you're working on developing software to communicate with a Host, and want to practice the protocol to be sure you understand the behavior correctly. But if you're working on testing the actual VCA records you're sending/receiving, this will give you a lot of effort overhead, and you're better off using already existing software from some device/machine/vendor used to send/receive data, and just test your data with them...

[Art]

Hi Yaron,

Thank you for clarification.
At least, now I understand what's going wrong with me and can start to communicate with this simulator

Indeed, I'm working for the company developing the device that should become an integrated part of the manufacturing process.
So, my software is an applicative layer that should exchange the information between manufacturing process (Host) and our device.
That is the reason I would like to understand and test a draft version of the protocol.

I use WinHex for the cases I need to edit the binary data.
If you have a better recommendation for the tool, I'll be glad to try it.
The same is true for the terminal itself. I don't locked on PuTTY, if there is a better alternative to use.
For example, I don't see it possible to send a full data block prepared in advance with PuTTY.

[Yaron [LaserOp]]

Hi Art,

Haven't worked with WinHex myself, but it should be more than fine. In any case the two functions you need to prepare a data file and transfer the full block are:

1. If you do this more than a few times, search&replace that will allow you to search for a text string (e.g. "<fs>" ) and replace with the hex value (e.g one byte of 1C) . If you already have a bunch of files then of course bonus points for search&replace across files.

2. The ability to select and copy the text data, rather than the hex data.

The second one, the ability to select the text, is the important one to transfer to a terminal like PuTTY. Right-clicking the PuTTY window will paste the clipboard content. so if you select the correctly formatted data, copy and then paste, you get the whole block in there. This should be very basic, I expect all editors to be able to allow you to select and copy the text in an edited file, correctly copying also the non-textual character. If not, heck, just save the modified file, open it in regular notepad, and copy from there (notepad won't show the control character, but it will copy them correctly).

For search&replace, as I wrote I'm not familiar with WinHex. If it lets you do that, and if it lets you do that across multiple files, then great, you're set. One hex editor I work with and know can do that is HHD's Hex Editor Neo, that supports searching the open file for text but replacing with bytes/binary data. It can also do that across multiple files, but that's a paid feature not available in the free version. Alternately, a surprisingly good option may be Notepad++ , it's a text editor, but the search&replace feature does support using character values in a regex replacement. And it works both for the open file, and for search&replace in files. So you can do a regex match for "<fs>" replacing with "\x1c" , which will work fine. It will preview the control characters in open files, and it will copy the data correctly.

The line separators are already fine in the text you already have (unless you're using something explicitly listing "<cr><lf>" in which case that really will be too much work to do manually), so you probably just need to deal with <fs>, <rs> and <gs>.

One issue it will leave you, is that to send from PuTTY you'll need to press the Enter key, which will send another <CR><LF> set that the simulator won't expect.

As an alternative to PuTTY, that would be easier to use in this scenario (you're basically wanting a clean/raw TCP/IP terminal/console, that can be handled easier), try WindTerm. Much better for this purpose than PuTTY. You can configure a TCP/IP connection, and it allows having multiple open "Sender" tabs at once that you can easily switch between to send different types of data. You can paste to it from somewhere else, add files directly, and it also allows to edit both text and hex characters inline. The interface is a bit clunky, but works well once you get the hang of it.

[Art]

Thank you for your tips and recommendations!

Now that I've grasped the basics :), I'm feeling a bit uncertain about the overall process.
From what I understand (please correct me if I'm mistaken), the host sits at the center and connects the devices. I represent one of the "devices," and there are others along the manufacturing line. All devices can communicate with each other and exchange data through the host. If this is accurate, in simulation mode, I need to initialize the simulator with the relevant data to access it from my application.

So, here the question comes: what is the best practice to do this?
Should I prepare a set of initialization parameters and transmit them to the simulator before running the application?
For instance, if I need to retrieve the weight of the lens, what would be the proper way to obtain its value from the simulator? 

Edited April 11 by Art

[Yaron [LaserOp]]

What you need is mostly covered in the DCS, which is generally pretty good. But I do agree (and from past experience being about where you are now) the DCS documentation is much better as a reference, where you already know what you're looking for, than as a guide or tutorial.

So let me give you a general overview here, and pointers to the sections of the DCS doc where you can look things up in more details. (the latest v3.14 draft was posted in these forums very recently, so you have access to it, I'll give section numbers from it, but also titles which are usually kept even if things move around between versions). Beyond that, it would probably be better if you open a different thread to follow up, either asking for more details on the general process, or about a specific part/label you're not sure about (so that better on the Q&A forum rather than the discussion one. That could help get attention from other people, who may follow these forums, who didn't see connecting to the simulator through terminal as relevant, but may see actual DCS usage as something to assist in.

(On one hand, I'm a pretty good source for your case, since I'm also exactly in the position of having worked on connecting our devices to hosts on the lines, so everything I tell you is true and usable, at a level where it works and worked in real life. But there are people here who may have experience with more than one device type, or who are from the Host/LMS side so have a much better general understanding of how things should work and how they happen with a much larger range of devices, so may be of better/more help if they do step in).

So at the basic level, the Host (usually the/an LMS) indeed manages the line in the lab, and all machines/Devices connect to it to get job data where a job reaches them (I'm ignoring here anything beyond machines on the line during job production, that need job data. If your device also needs to measure/test something and modify job data that other devices down the line will need, there's more to do, but this is still the same basis). For the very basics, do go over the DCS doc sections 3 "Terms and Definitions" and 4 "Overview" , 5.1 "Requirements"->"Records & Datasets" , and 6.1 "Packets"->"General" .

Your device knows what data (which Labels) it needs to process jobs (e.g. if you need to know the weight of the lens then you'll need WEIGHT). So it needs to let the Host knows which Labels to send it. For that there is an Initialization process (Start with 7 "Sessions" for more general overview in 7.1 "General", and 7.2 is "Initialization Sessions" which is this. Realistically you want autoinitialization / auto-format initialization, which is the recommended way to work, and is widely supported). For this you tell the Host you want to do initialization, and if it supports it, you send it information about your device (in case there's any specific changes/tailoring they want to do) and a list of the Labels you'll want (including here WEIGHT, which you'll send as part of the D=<labels you want> set in the DEF block). It would then give you a Request ID representing your set of definitions.

Then, when you need data for a job, you send a job data request, with the job number (obviously) and that Request ID from the initialization. You can keep using the same Request ID until you need to change what you're asking for (and so do initialization again), or the Host tells you it doesn't recognize the ID and you need to do initialization again (in which case, well, do initialization again).

This works for real Hosts, and also with the Simulator. For the Simulator the records/labels it has for a job are in text files it keeps (and you can create/edit) for each job. So whatever job data you want it to send you, of course put it in the file in advance. Notice that the files contain the labels for the job data, but nothing beyond that, so no reserved/control characters like <FS> and such, and no STATUS label which the Simulator (like other hosts) will send based on the situation (that's how you know if you get job data correctly, no data for this job, errors, need initialization, etc..., take a look at A.4 "Status Codes" and the associated table A.24 "Status Codes" ) .

The documentation should show you example both for the initialization process (with REQ=INI packets), and getting jobs (with REQ=<the id> and JOB=<the job you want> ) .

[Art]

Thank you so much for your assistance, Yaron!

I'll begin here and initiate a new Q&A thread if necessary.
Wishing you a great weekend!