All Activity

This stream auto-updates     

  1. Past hour
  2. Section 7.3 for Sag Charts Rather than have Lines be an array of strings, why not do like: "Lines": [ { "Base": 6, "Add": 1, "Radius": 15, "Angle": 0, "Sag": 3.17 }, { "Base": 6.00, "Add": 1.00, "Radius": 15.00, "Angle": 15, "Sag": 3.56 }, ... ] No need to multiply by 100 and naming the values gives more clarity.
  3. Fixes for the example in section 4: Use the standard double-quote char everywhere - some non-standard ones are in the example (e.g. “Product IDs” versus "Product IDs") "Blank Collections" section - remove the last comma after BLK-YYY-010 since this is the last element in the array I attached a working file after the fixes above. Suggestions for consistency: Consider renaming UsableDiameter to have a space - same for RightOPC, LeftOPC, RightID, etc. as the convention seems to be space separated names like: Capitalize words in the names - change "Owner name" to "Owner Name" and "contact" to "Contact" Clarity on JSON Arrays In section 7.3 RFC 7159 says "An array is an ordered sequence of zero or more values." So, something like [1, 2, 3, 4, 5] must always be in that order. If a JSON parser does not maintain that order, then the parser is faulty. lpds-example.json
  4. Today
  5. Dear Colleagues, Please find attached to this post the draft of the new Lens Product Description Standard. Please post all comments, questions, suggestions and critiques in this thread so that we can keep the process transparent. If you have specific concerns you are not comfortable addressing publicly please feel free to email them directly to me. Regards, Paul TVC Lens Product Description Standard 0.78-DRAFT.pdf
  6. Last week
  7. Hi Everyone, Find attached to this post the shape data presentation given by Sebastien Peña-Feldmann at our meeting during VEW. Paul VCA_BSHAPE_2.pptx
  8. Earlier
  9. A Network Service Desk Engineer has to be prepared for working in a fast-paced working environment and has to be able to identify and deal with problems quickly.Apart from what is shown as part of the network service desk engineer job description, they have to be prepared to provide a quick response to any issues that arise. A business will expect network service desk engineer skills to include the ability to diagnose and solve problems when they occur, providing help desk support for the network.

    While giving priority to any issues the staff may have, they should be able to gather and analyze information that will result in identifying sources of errors and resolve performance issues.

    They are also responsible for documenting security procedures and standards and will deal with third party vendors to evaluate benefits and costs. This can involve in-depth analysis and research on customer networks.

  10. Hi All, I've uploaded the DCS meeting audio to Google Drive: https://drive.google.com/file/d/1GHcSJUumB0_hTXO1meQtm59OOi2UM1Bs/view?usp=sharing Please let me know if you have any issues accessing the audio. Please note that the recording does start during introductions. Thanks, Paul
  11. Hi All, I've uploaded the LPDS meeting audio to Google Drive: https://drive.google.com/file/d/1RGV09RFv4FxxT1zToohDaefSTsi_tdiL/view?usp=sharing Please let me know if you have any issues accessing the audio. Please note that the recording does start a minute or two into the meeting. Thanks, Paul
  12. 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.
  13. 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
  14. until
    Location: Sands Expo & Convention Center, Las Vegas, NV Meeting Room: 307
  15. until
    Location: Sands Expo & Convention Center, Las Vegas, NV Meeting Room: 307
  16. 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?
  17. 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.
  18. 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", ] } }
  19. 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
  20. I would agree on using PIND for SLBP
  21. 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?
  22. 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
  23. 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)
  24. 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
  25. 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.
  26. 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
  27. 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.
  28. 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.
  29. Here there is an example for 2 IOT products. One of them using collections of lens blanks provided by a different vendor. https://drive.google.com/file/d/1WOeT749fTRTYdJcw1eub9apVTHAKSlR7/view?usp=sharing
  1. Load more activity