All Activity

This stream auto-updates     

  1. Earlier
  2. I am not sure if there is any lens analyzer that can verify the position of the MRP (fitting cross) from the blank center. For sure there are mappers that can verify the position of the lens power maps, which is a relative position to the engraving reference points. There is no standard for the possible shifts of the lens power map either, which could be horizontal, vertical and rotational.
  3. Hi, Anat; Did you have a proposal for how you would represent the upper and lower limits, as well as the nominal base, for your Rx ranges, using a model similar to what Steve proposed? At first glance it appears that Steve's proposal could handle this by adding two additional columns for min and max base curve, using the existing column to represent "preferred" base curve, perhaps. The end result would be more complex and require additional boundary identifiers, but I think it could work. Is this along the lines of what you had in mind? (I do not want to presume to speak for you on this, but because this seems to be a Shamir-specific request you might be best able to suggest how this could be represented). A design such as you give may not be supported today by all LMS systems; I know in our case we would use upper and lower limits when they are provided by the LDS in response to a BRS request, which is what we do today for Shamir integrations, but we don't have a means of indicating multiple valid ranges of base curves for an Rx when we use a base curve chart. We can handle a 3-dimensional model, using sphere, cylinder, and add, but only to specify a nominal base. Of course, whether LMS systems today can support it does not impact how and whether we represent it in a new standard. Tony
  4. until
    Location: Sands Expo & Convention Center, Las Vegas, NV Meeting Room: 307
  5. until
    Location: Sands Expo & Convention Center, Las Vegas, NV Meeting Room: 307
  6. I agree, there does not seem to be any existing labels which return the location of the distance MRP for all designs. Should we also have labels which define the location of the distance MRP relative to the center of the blank, for use by analyzers which check the lens before mounting?
  7. For myself, I agree - it seems unnecessary to have a separate characteristic family which is uniquely used by the blank collection. I can't think of any requirement for characteristic family outside of the blanks.
  8. In working on the standard with where we'd last left it, we've encountered an issue with the division of certain properties. We have two objects that we'd like to combine in to one. Blank Collection : Groups like lens blanks together, and contains an array of blank IDs. Can optionally point to a Characteristic Family, which, if it does, enforces that all associated blanks share the characteristics contained in the Characteristic Family. Characteristic Family: An object containing the inherent Material, Design, and Treatments for a linked blank collection. What I don't like is the number of steps and amount of description it takes to link a blank to its material or inherent treatments, requiring this extra step of traversing through the blank collection to a characteristic family. I'd like to put the properties that are on the Characteristic Family on the Blank Collection instead, and entirely do away with the Characteristic Family. So that if these properties are present on the Blank Collection, they apply to all associated blanks. I think that would greatly simplify understanding this bit of the standard. For examples - Currently {"Blank Collections": [ { "ID": "BCO-YYY-000001", "Characteristic Family ID": "FAM-YYY-000001", "Label": "SF FF Polymer 1.5 - Hard Coated Pucks", "Blank IDs": [ "BLK-YYY-001", "BLK-YYY-002", "BLK-YYY-003", "BLK-YYY-004", "BLK-YYY-005", "BLK-YYY-006", "BLK-YYY-007", "BLK-YYY-008", "BLK-YYY-009", "BLK-YYY-010", ] } ], "Characteristic Families": [ { "ID": "FAM-YYY-000001", "Material ID": "MAT-YYY-000001", "Design ID": "NA", "Blank Collection IDs": [ "BCO-YYY-000001" ], "Inherent Treatment IDs": [ "TRT-YYY-000001" ], "Required Treatment Types": [] } ] } Proposed {"Blank Collections": [ { "ID": "BCO-YYY-000001", "Material ID": "MAT-YYY-000001", "Design ID": "NA", "Inherent Treatment IDs": [ "TRT-YYY-000001" ], "Required Treatment Types": [], "Label": "SF FF Polymer 1.5 - Hard Coated Pucks", "Blank IDs": [ "BLK-YYY-001", "BLK-YYY-002", "BLK-YYY-003", "BLK-YYY-004", "BLK-YYY-005", "BLK-YYY-006", "BLK-YYY-007", "BLK-YYY-008", "BLK-YYY-009", "BLK-YYY-010", ] } }
  9. Do we have DCS labels for the inspection of PDs (Distance and Near)? I can't find them. If we don't I think that we should add INSIPD for Distance PD inspection and INSNPD for Near PD Inspection
  10. I would agree on using PIND for SLBP
  11. The standard does not specify what index SLBP should be expressed in - in the opinion of others, should SLBP be expressed in PIND as with other prism labels?
  12. I am a Staff Author at Field Engineer a Marketplace for On-Demand telecom workforce, extending from field engineers to high-level network engineers, project managers and Network Architects in 146 nations. I am an IT Engineer.

  13. Attached sample of Shamir product base chart. As you can see for some of the Sphere power we have some bases that we can produce but only one of them is the primary. e.g.: for SPH=-2.00 the primary base is 3.00 and the secundary are base 4.00 and 5.00. I will be happy to add more information if its not clear. Autograph III 18 - HI Polar Brown.pdf
  14. Shamir also prefer option number 2 with some notes: Add field to LDS file that indicate if we receive measurment value or defaultr value. Shamir, as a vendor, should have an option to send this default value to LMS systems by LPDS protocol. As i see it we have an impact on 2 protocols: 1. LPDS - set default value for some of parameters. 2. DCS - add fiels or flag that indicate the type of the value (measured or default)
  15. Hi Nick, First, just to be clear, this is for the new standard still under development, not the existing LDS. The problem is that we do not have a standardized, universally unique way of identifying things outside of physical lenses. OPC's work for that and while expanding the use of OPC was discussed it's not really feasible for this purpose. So it's really about more than packages. No user of the standard would be forced to create packages in their LPDS catalogs but if they want to we would like to have a single ID methodology that can be applied to those as well. I think your last bullet is on point... I believe that is exactly what the group is trying to develop. Regards, Paul
  16. During the LPDS Committee meeting (and the DCS meeting) an issue was brought up surrounding parameters and allowing the LDS to specify that parameters should not be filled with defaults. The specific example discussed was that when POW values are sent to the LDS these are sometimes filled by one of the systems between the patient and the LDS (LMS, PMS etc). Ideally this should not happen and it would be beneficial for the LDS to specify this. This issue could be handled by adding a field to the parameter object which specifies that the parameter can not have defaults applied. Alternatively a field could be added which specifies the source of the data (ie Patient) which implies it cant be filled at any other point in the system (this option would be my preference). Any further discussion or comments would be appreciated.
  17. Couple comments from lens manufacturer/lab perspective: what is the problem that is trying to be fixed? I am coming late to the party and just curious so I can better understand the goal of this Having OPC/IDs for packages I believe is excess Many times "packages" or Marketing campaigns are temporary.. so why go through all this work for something that would be obsolete a few months later? This presents another step in launching a Marketing campaign which could potentially limit your ability to respond to market demands quickly (it takes time to request identifiers, load them in our system, then load them in LMS systems, etc) if there was some sort of design identifier that all LMS companies can recognize, this would make the process much more efficient and easy to use from a lens designer perspective Hope this helps and look forward to the conversation. Nick
  18. During the LPDS Committee meeting the working group presented their proposed implementation for concise base cure and range chart definitions. This proposal is outlined in this thread: During discussions at the meeting representatives from Shamir pointed out that this method does not allow the specification of an allowable base curve range for a specific power combination. The group requested this topic be started so further discussion could take place between now and our next meeting at Vision Expo West.
  19. Starter topic for discussion of product ID's to be used in LPDS to include identification of "packages" which may include lenses and various treatments. Please post your thoughts, questions, concerns, etc. If you have any specific proposals on the creation of product identifiers please feel free to share those as well.
  20. Here there is an example for 2 IOT products. One of them using collections of lens blanks provided by a different vendor.
  21. Agenda for our 2019 VEE meeting. 2019 VEE - DCS Agenda - FINAL.pdf
  22. I also added the DCS fields for polarized film details into the Blank; PLRCRV & PLRLOC
  23. Hi Steve, We have updated the Zeiss complete example to use the changes you have made above, excluding alphabetical ordering of fields. This example is larger than required for the working document but can provide a second reference. It can be found though the following link: Updated Example - Google Docs (I recommend turning print layout off when viewing the document) I have also added some suggested changes to better map fields in Blanks to their respective DCS fields: Base -> MBASE Addition -> ADD Front Radius -> FRNT Back Radius -> BACK
  24. I've updated the working definition, which is still using the same file location as before. I've modified it so that some of the naming is more consistent now. A reference to a list of other items defined elsewhere in the document has a name ending with "IDs" A reference to a single item defined elsewhere in the document has a name ending in "ID" The Owner value has been removed from each object, given that the ID now incorporates the owner. Alphabetized fields, to make tracking down missing ones easier (Though I stopped doing Blanks after the first few). Changed the way treatments were included in the Characteristic Family to match how it was done at the product level, with using specific lists indicating requirements such as "Required Treatment IDs" I've also included a diagram of that JSON structure. Each box has three sections that are delimited by a horizontal line The first section indicates the name of the node. If there is more than one line in that top section, it indicates a child object of the parent. The second section is for values that are either the object's ID, or references to another objects ID The third section is for values that are not foreign keys, and are informational about that particular object. I think adding all the lines that would point to Parameters and Treatments would make the document a lot more difficult to read, so I've left those out. But, a name that has "* Parameter ID(s)" or "* Treatment ID(s)" will indeed be referencing objects in those appropriate nodes.
  1. Load more activity