All Activity

Thanks a lot, Yaron, for explanation

Are you the device asking for trace data, and receiving this? Because in this case I'd really recommend, during initialization, to ask for trace if format "1" (ASCII absolute), instead of "4" (Packed binary). This would be both a lot more readable (or, well, just plain readable) for you personally, as well as easier to code for (assuming you're using a language with something that has basic text/string processing capabilities). As for what this tells you, first, the TRCFMT line, tells you (besides that it's for the right lens): 1. That data (i.e. radius distances in the R records in this case) will be in the packed binary format (hardest to read/use, really no reason to do that if you don't have to, or need to be able to work with extremely low bandwidth or memory). 2. That you will get 512 radius distances in the R records (main data of the frame traces. Each value is radius distance from the center position of the frame). 3. That the angular distance between the R values are equal, so the total 360° will be spread equally, effectively giving you a radius over a sequence with about 0.7° rotation between them. 4. That the frame trace you're receiving is from tracing a frame, rather than a demo value or a pattern. (probably not actively useful for you beyond basic verification you're not receiving something unexpected) And, of course, the R record, which has the actual shape of the frame trace, as a sequence of the radius distance from the center along the circumference of the frame shape. Your main issue with reading this is, again, that "4" Packed Binary format, which is not particularly human readable. You can see the details of the format in the DCS, section (in 3.14 ver03) 5.4.15.4 "Packed binary format". Though, really, read all of 5.4 "Tracing Datasets" , for a cover on how to read frame trace data. The main records you care about are TRCFMT and R. Good idea to also look at A for when the angle distances aren't "E"/equiangular but "U" (rare but happens) or "C" (so far very very rare). Depending on what your device is/does, it's possible you don't care about sag data ZFMT/Z/ZA at all, otherwise behavior is generally similar to the main trace data. Notice that if you're not reading files with pre-made trace data (in which case what it has is what you get), but are instead asking a VCA Host for the frame trace, then you can on initialization specify which formats you want/support. Most modern LMS will probably be able to convert/interpolate whatever format trace they have to whatever you asked for.

Hi Ryan, At first glance, everything does seem to be fine. The trace data you sent is formatted correctly without doing anything unusual, and there even isn't any obvious mismatch (at least at the "eyeballing it" level) with related records like HBOX/VBOX/CIRC if the machine tests them. So, while I'm not working for WECO so can't be sure what/how this machine is doing, a few guesses on what might be causing it the problem: 1. Maybe it's only expecting "Frame" traces and doesn't know how to handle the "P" type for Patterns (fifth field of TRCFMT record) ? The behavior should be exactly the same, it shouldn't technically matter, but if it's explicitly matching "F" there for supported types, it would obviously decide it doesn't support what's traced so can't use it. Try sending as F instead of P to test if this is it (e.g. instead of "TRCFMT=1;512;E;R;P" send "TRCFMT=1;512;E;R;F", and same for left side) . 2. Maybe it can't handle the ZFMT records? It's just ZFMT=0, which is the default when ZFMT isn't sent, so ignoring it is the correct behavior. But if it's expecting to just not get it (which normally it probably really wouldn't in this case), and if it's expecting to get the two sides of the trace as a block (which it technically shouldn't expect to, but in practice is what would practically always happen), then the ZFMT in the middle would be an unsupported label in the middle of the trace data. Try just not sending ZFMT instead of ZFMT=0 to see if that's it. 3. Is it actually expecting a trace of this type? Are you sending frame trace of "1;512;E" because it was agreed upon during initialization, it was in the list of formats in presented as supported, and was the format the host sent it as agreed upon? Or did the machine specify a different format/resolution, without including this one in the list of supported formats? Your communication log is using an already negotiated Request ID and doesn't include the auto-initialization, so I can't see how initialization went, but it's something you should verify. Possibly the machine is finicky on that. Ideally it should be fine with accepting anything that it knows how to handle, but technically there's one format agreed upon so only one it should officially receive (even if in practice most machines probably don't really care and it's just extra work for both sides).

I have attached the information we send to the WECO E12 including the trace. I appreciate you assistance. WECO E12 English Log.txt

Hello all, Can someone explain how to read the TRCFMT messages? For example, 15:54:18:230 : PACKET : TRCFMT= 4;512 ;E; R;F<cr><lf><lf><cr> 15:54:18:230 : PACKET : R=]<09><00><80><09><80><1F><F1><01><FF>/<01><E1><F1><00><0F><1F><00><F0><F0><0F><00> 15:54:18:230 : PACKET : <FF><00><E0><E0><F0><0F><FE><0F><00><FF><esc><9E><0F><F1><00><F0><1F><10><F0><F0> 15:54:18:230 : PACKET : <1F><10><1F><01><10><00><esc><91><esc><9C>0<00><E3><01><F1><F2><0F><01><00><F2><01> 15:54:18:230 : PACKET : <1F><00><01><00><10><01><00><01><F1><01><00><F1><00><esc><91><F1><01><F1><00><F2> 15:54:18:230 : PACKET : <01><00><00><02><E1><10><00><esc><91><0F><esc><91><00><01><10><01><F0><esc><91><0F> 15:54:18:230 : PACKET : <FF><esc><91><FF><C0><FF><FF><EE><0F><EE><00><F0><F0><esc><91><00><01><F1><1F><00> 15:54:18:230 : PACKET : <10><01><0F><10><01><0F><00><00><F0><1F><0E><F1><10><E2><00><1F><10><F1><F1><0E><10> 15:54:18:230 : PACKET : <00><01><F1><0F><10><01><F1><00><01><FF><esc><91><0F><10><00><10><F1><00><00> <F2> 15:54:18:230 : PACKET : <FF><1F><01><E1><00><F1><FF><00><E0><F0><F0><00><EE><E1><esc><91><C1><01>.<F0>!<E0> 15:54:18:230 : PACKET : <F1><esc><91><0F><F1><02><1F><E0><esc><91><F2><01><E1><1F><1F><esc><91><F1><FF><esc> 15:54:18:230 : PACKET : <91><01><00><E3><F0><00><02><F0><01><00><0F><1F><02><F1><01><FF><esc><91><E0><10> 15:54:18:230 : PACKET : <1F><1F><10><F1><F1><F0><00><0F><esc><91><esc><9E><10><F0><0F><esc><91><F0><00><F1> 15:54:18:230 : PACKET : <F0><10><F1><01><F0><01><F0><00>/<01><0F><10><F0><01><F0><10><01><1F><0F><10><00> 15:54:18:230 : PACKET : <esc><91><0F><00><00><10><10><00><esc><91><E0><esc><91><0F><00><cr><lf><cr><lf><lf> What should this data tell me, except that this is a trace for the right lens? Thanks!

Hello all, Is there any NuGet packages or third party SDK products available that implement DCS protocol/DCS standard? Thanks ahead for answering

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!

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> ) .

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?

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.

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.

Michael, I answered Artiom with more info and suggestions on the other thread, that he opened and also added a screenshot of the attempted connection showing the data sent and what the DCS Simulator received, in the other forum ("DCS Discussions"). Not much advantage to having this going in two places, I'm adding here a link to the other original discussion if anyone sees this here and wants to follow, but if as an admin/mod you have a better way to merge these (or just remove this thread if nobody is following it specifically? Are there people who follow the Q&A forum and not the Discussions forum?), then probably a good idea to do so.

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...

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?

Artiom has asked this question and needs some assistance. "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”. Can you guide me what should I configure on my terminal to make the simulator understand me?" Thanks, Artiom O.

Hi Ryan, Can you post the actual data/trace that you're sending? Assuming there is some actual issue (whether it's something incorrect/off in the trace data itself, or just something correct but a little unusual that possibly the edger isn't expecting so doesn't know how to handle), seeing what the edger receives would be... helpful... to try and guess what causes it a problem. So please provide at least a trace that the edger complained about, though ideally the full communication log between the LMS and server on a job with a frame trace that caused the problem (in case the issue is maybe not with the trace itself but a mismatch with some other related label).

Hello DCS Group, We have a member company that have ask the following and i was hoping someone would be willing to assist them. We are using the Frame Drill Mount Standard form trying to “reverse engineer” the drill points by manually entering them into the TXT file tracing report. This is so the end result is an .OMA file with drill points (and so "we" do not have to buy a new pricey machine to use twice a year). If you are willing to assist them, email me and I will connect you. Thanks in advance

I am trying to install a new Visionix Weco E12 edger but the trace data I'm sending is causing an error. "Invalid OMA Frame" When I send no trace data I don't get any errors. I have integrated dozens of machines over the last 30 years but am stuck on this. We use a proprietary LMS. Anyone else encounter this error? Weco is not being helpful.

Dear DCS Members, The following was sent to me via email. I’ve asked Ryan to join and post his question here in the future. Is there a diagram or document that explains how the z values are calculated? I know it represents the sag at the eyewear but which radius does it use for the calculation? Ryan Maxwell President OPTIK K&R Inc. Eric Boisvert Eric.Boisvert@kandr.com Ryan Maxwell ryan.maxwell@kandr.com

Hello all, Thank you in advance for those who are able to attend the upcoming virtual meeting. Please find attached the version 3 draft of 3.14. I've included tag requests from our past meeting, as well as gone through and added a representation of the TOL/TOLV/INS/LD records, where possible, in new columns on the right side of table A.1, with descriptive sections in A.1.1.7 through A.1.1.10 I do plan on requesting feedback on how we should go about support the rest of the tags that don't have a corresponding non-prefixed tag. Thank you, -Steve Edit: I forgot to mention - if you see the file but are unable to download it, please ensure that you're logged in, as downloads aren't available if you're not logged in. DCS_v3.14_Draft-003.pdf

Thanks, Bill! I do intend to schedule a meeting with you, Ronald, and Marc to talk about the Swarf. If you are all at the Vision Expo East, we can meet in person as well.

To get the ball rolling, I wanted to start something to try and outline some of the lab-specifc areas of concern. That way those of you in the lab space can add on here, and those of you not in the lab have a better understanding of some of the areas of concern we have. Swarf This is probably the number one in the lab. Swarf is the bits of material left after cutting a lens blank. This is where it goes from a hockey puck to an optical lens with a prescription. The main problem with finding a good way of recycling this has been the bulk/cost involved, as well as the mixed nature of the materials. Since lenses come in a wide variety of materials, the cutting waste is also mixed. Plastic (CR-39) tends to leave a sand-like residue after cutting, while polycarbonate leaves string-like material, much like fake grass in an Easter basket. Alloy Alloy is used to hold lenses in place during the cutting process. It's reusable, but it does contain elements such as lead, and cadmium, so it isn't exactly environmentally friendly. While there are some more environmentally friendly options available, they tend to be less reusable and substantially more expensive. Packaging Materials More standard here -- frame tags, poly bags, envelopes.

Authors: Dani La Gace and Justyna Grzegorczyk(Szacon) TVC_ESSAC_Glossary_Rev (1).pdf

We would like to thank you for your participation in our recent survey. Your valuable feedback is incredibly important to us, and we truly appreciate the time and effort you took to share your thoughts and insights. ESSAC_Survey Results_November 2023.pdf

Dear All, please find attached a copy of the presentation regarding OPCUA as an option / discussion point for machine to LMS communication presented at the VEW LPDS meeting. 20230920_OPCUA-for-DCS.pdf