Jump to content

Report default fields Edit?


---
 Share

Recommended Posts

C:\Users\Public\Documents\Zeiss\CALYPSO 7.0\protocol\protform - (systemfieldassistance). Can I edit this file?

Looks like maybe I can't. I changed the Lotid to Lot_Number and there was no change. Maybe this is the wrong file to edit?
Link to comment
Share on other sites

What are you trying to accomplish?

The proper method is not "changing" the identifier for default report header parameters. If you require a new parameter, you should create one rather than edit existing defaults.

This can be done from; Resources > Design Custom Report > Editor for User-Defined Report Header variables...

Be sure to add the variable, define its properties and map it to a k# value for PiWeb filtering options.
Link to comment
Share on other sites

  • 2 weeks later...
Hello,
I would ask you about similar topic.
How can I define K#16 to export to PiWeb DB?

I don't want to add it in Userfield.ini, because its standard Qdas Key.

I tried adding it in Systemfieldsassisance.ini and It seems OK, but when I run measurement program the K#16 doesn't appear in CNC start menu.

We use standard protocols for the most measurements not PiWeb.
Is any way how can we have K#16 on standard protokol (Calypso editor) and on tabulle CNC Start without user-define field?

We also dont use Multireport mode. We have one standard protocol for each measurement.
Link to comment
Share on other sites

Please sign in to view this quote.

I understand this is how it works but why? Most of the default names are irrelevant to me. Now I have a bunch of predefined field names that I can't use. This wouldn't be a problem, but you are limited to how many user defined fields you can create; Unless you are willing to pay. Try explaining to management that they have to spend 20K just to change the name of 3 fields.

How do I get Zeiss to change the name of the default fields to all the field names that I use?
Link to comment
Share on other sites

Please sign in to view this quote.

I believe PiWeb will limit your user defined fields unless you upgrade. Honestly, I should probably check my facts before I post but it sure did sound good.
Link to comment
Share on other sites

Please sign in to view this quote.

In this day and age, what SOUNDS like it SHOULD be true is BETTER than what may or may not ACTUALLY be true!
#AlternativeFacts
Link to comment
Share on other sites

The "mappable" limit of K-values within Calypso to PiWeb is 10. It is a hard limit. This is not "licensing" issue but I have been told that it is something that is being looked into for enhancement in newer versions. You can add as many userfields as you see fit using the userfields.ini (old method) but they are not "mapped" to the PiWeb database and therefore not able to be sorted natively through the filters. The added K-fields from the userfields.ini will still transfer to reports as text/values but you are unable to search for them and use them as filtering criteria.

So if you are just looking at a way to add custom names for variables, the userfields.ini is how to add as many as you would like. Just be mindful that only 10 that you map to K-values (I believe it is K20001-K20010 off the top of my head) can be used for PiWeb database filter criteria.


There may be a way with SBS or Enterprise with customized XML configuration files but the file structure and formatting for those software systems are completely different (even from each other) so the solutions for those versions does not usually apply to Reporting+

I have created custom solutions using PCM that applies the value of an added variable to a default mapped variable then changed that variables display name in the PiWeb PTX but that is not a robust solution unless you use a single PTX report and make an explicit note that your value is passed to PiWeb using a modified K-value channel. Otherwise, confusion will most certainly be a result down the road. The PiWeb filter will also be the default mapped name. That cannot be changed on the user level. I am not advising that use but I am saying that in a pinch, there is always a way if you are creative.
Link to comment
Share on other sites

Please sign in to view this quote.

But if you upgrade your license to SBS then it works. Got it.

Please sign in to view this quote.

I'm just pulling your chain BTW.
Link to comment
Share on other sites

Please sign in to view this quote.

Lol

Im not even sure that there is a way with SBS or Enterprise but each time I say something isn't possible with SBS or Enterprise either, I am kindly shown that I am mistaken. There isn't a documented way that I have found even for those two versions of PiWeb but they are completely different animals to Reporting+. They are similar in name and appearance only. The backend is almost completely different for each. They only look similar at the CMM user level.

I am positive on limit of 10 mapped custom named variables to Reporting+ however. I have asked for more myself for a very important project but was told, at that time, that it wasn't possible due to some application code restriction/conflict. This was also for an SBS environment which is why I say that it may not be possible there either.

I hope I gave you some direction and info on how to go about your process continuing on.
Link to comment
Share on other sites

You can only map 10 custom variables, but you can add as many custom ones as you'd like inside of the GUI - no need of doing it through the .ini.

The problem with not having it mapped, is that you cannot sort via attribute, and assigning the attribute inside of a PiWeb report is a bit of a pain, but it isn't too bad once you learn the text string.

When you create a custom variable, it will have an internal name. The text string to pull the custom variable is
${Qdb.Property("Internal Name")}
so for example I made a custom variable called
NotMapped
with an internal name of
u_NotMapped
. Inside of the text box to pull the data of that variable it would look like this.
${Qdb.Property("u_NotMapped")}
Link to comment
Share on other sites

In the future there will be more and more digital data exchange. Digital data exchange works best when you don't need to map data.

Attached are some tips for reporting.
Have a look at " Use of Simple Structures for Easy Data Exchange.If possible, use finished protocol head variable"
882_3c69911042c453d49237f2f631d5a997.pdf
Link to comment
Share on other sites

  • 3 weeks later...
Hello all,
I'm sorry for my late.

I though Calypso has same Keys like QDas norm. But I was wrong.

Calypso has only a few Keys like Qdas. It is horrible to compareKeys PiWeb and Calypso.

We don't use multireporting and some fields don't work (its value doesn't appear in CNC start table) like "cavity", and added fields from PiWeb.

Is there a way how create a report with standard field names and QDas Keys?
Or do I have to use mapping Keys (20001-20010)? Seeing the answers, there is no other way.

I know how do it, but amount of Keys is limited. 🙁

With the use of multireport it would be simpler.
Link to comment
Share on other sites

The q-das keys are for the qs stat converter.
The configuration for the qs stat export is located in C:\Users\Public\Documents\Zeiss\CALYPSO 7.4\qdasconv.con

The q-das format is very limited: Plot data, images, CAD models, Meshmod data... are not possible in q-das format.

PiWeb / PiWeb reporting can transport all data. Therefore the key numbers can be different or additional numbers are necessary.
We have strengthened "digital data exchange of measured values" between companies. The more individual configurations are possible, the more difficult it is to exchange data in a standardized way.

If, for example, 4 different companies/departments use different variables for the same data field (e.g. order), digital data exchange becomes difficult. In such cases you always have to program a cross mapping

If possible, use standard fields for easy data exchange.
Link to comment
Share on other sites

 Share

×
×
  • Create New...