All Activity
- Past hour
-
[ni...] started following Error Piweb report generation
-
Bonjour, Depuis peu, à la fin de la mesure de mon programme, le rapport Piweb ne fonctionne plus et affiche une erreur " valeur hexadécimal 0x0C est un caractère non valide. Ligne 46, position 619." Je n ai aucune idée du pourquoi et du comment. Si j active le protocole standard, cela fonctionne parfaitement. Savez de quoi cela peut venir ?
- Today
-
[Ma...] joined the community -
These are all settings in qdasconv.con, where you specify whether it's dfq, dfd+dfx. As Martin says, everything is contained in dfq, and dfd and dfx are divided into attributes and results. The path is also set there and is valid. If you want to do it temporarily, I would make a copy of the file, change it, and then restore the original later.
-
The same here, would be nice to have a solution in time.
-
[Ol...] joined the community -
[Yo...] joined the community - Yesterday
-
[Re...] joined the community -
"Failed to log in" Error when clicking on Log In in Zeiss Quality Suite
[Ro...] replied to [Ho...] 's topic in General Discussion
Hello, same problem, no login possible at Quality Soite -
[Ro...] joined the community -
[Ch...] changed their profile photo -
Calypso 2025 Issues - URDF or Interface File Missing? Illumination Files Invalid?
[Ch...] replied to [Co...] 's topic in General
I'm pretty sure Cory did a complete uninstall and re-install of Calypso 2025 with the latest patch "8.0.1203" then created a new master probe + imported other probes and that seems to work in simulation. -
@Donny Fraser, Very interesting approach. Thanks for sharing about it. It sounds like this is a strategy that others have found to be effective. My first inclination would be to probe the datum simulator surfaces that the workpiece's datum features contact. This requires that the datum simulators have minimal form error and that the workpiece makes proper contact with them. However, I love hearing alternative approaches including best-fit alignments. Keep us posted on this project, and I would love to hear how it turns out.
-
[Wi...] joined the community -
[Ma...] joined the community -
[Ja...] joined the community -
[Ro...] joined the community -
As i tested - that Name for output files is only for path - file name is default as program name. Perhaps QDASCONV can solve file name, but i have a workaround with BATCH file to do my things. For us we use DFQ - it's all in one file - DFD and DFX should be separate files i think
-
Maybe check for a hidden sab file? Would Calypso see a hidden sab file?
-
[Je...] joined the community -
Does anybody know how the individual path settings for Q-DAS files under Resources -> Name for output files go together with the output path in QDASCONV.CON? Does one override the other? If so, which one has priority? And if the individual path is in effect, which type of output file(s) (DFD, DFX, DFQ) is written? This setting looks a bit contradictory to me. Has anyone already used it an can enlighten me? I'm looking for a way to have a Q-DAS file of ALL measured chracteristics written to a seperate path whenever needed, but only temporarily. I don't want to change my usual Q-DAS output settings in QDASCOV.CON. Is that possible somehow?
-
@Bolfin Paiz https://portal.zeiss.com/knowledge-base?id=415735
-
-
No change with DeviceActivator. To the hotline....
-
Not much documentation. The official PCM manual says: From other sources:
-
Hallo, gibt es zu den PCM Befehl "outputMultiQdas" eine Dokumentation? Gruß, Matthias
-
@Tom Oakes If i received this issue as an Support Ticket, my first suggestion would be to run the device activator. It just adds ID's to the controller, there is nothing to worry about when installing it. If that doesnt help you should create a Support/Service Ticket and let my colleagues investigate further. To me it looks like a hardware/controller issue since the data loader is based on the controller.
-
@Marcel Hartmann Based on my posts on the problem, do you feel the device activator would fix my issues?
-
I re-booted everything. Now, I am getting a new error (below) when gets to home position after restarting. No CAA data issue if I home the cmm before starting Calypso. Now, it won't even store the MasterProbe. Me thinks something is wrong with VAST-Gold sensor.
-
[Qu...] started following True position error on an inclinated bores pattern
-
@Tom Oakes As far as i know you need to run the device activator also when there has been a change of the sensor itself, because it also has a unique ID!
-
@Marcel Hartmann Would it be necessary if the VAST-Gold sensor was replaced in December? There are no new adapter plates.
-
The Device Activator is also for the active sensors like VAST Gold or VAST XT Gold, it gets updated every ~6 weeks on the portal and has new plate ID's included for the new created Adapter Plates. When you buy new adapter plates there should always be a red sticker attached to the plate packaging which says to run the device activator. Best Regards Marcel
-
In the guide, I don't see any mention of VAST-Gold or VAST-XT-Gold. From what I see, this is only for VAST-XXT. Is that right?
-
[Pi...] started following Optical 3D
-
This error only happens when the stylus system is going into the probe rack to drop it off. If I manually put the stylus system in the probe rack, it picks it up fine.
-
Hi, is it possible to create a ticket via internet (webpage)? Or to give an email to send the details? Thanks!
-
ood morning everyone, I am currently working on a spherical part featuring several inclined holes, and I am looking for the best way to measure their position error. My base alignment is set as follows: Origin: Centered on the central hole. Rotation (Y-axis): Oriented using one of the outer holes. Z-axis: Levelled to the external plane of the sphere. For both the central and the orientation holes, I measure them as cylinders and then calculate the intersection point between the cylinder axis and the sphere surface to define the alignment features. All subsequent holes are also measured as cylinders. As mentioned above, their true position is evaluated at the intersection point between each hole's axis and the sphere surface. I only measured the holes located along the Y-axis line, and then I created radial patterns for the rest. The problem I am encountering is that as I move further away from the hole used for the Y-axis orientation, the position error increases exponentially (as shown in the attached graph). I have already tried using the intersection with the plane instead of the sphere surface, but the results remain unchanged. Does anyone have suggestions on how to achieve more accurate and reliable values? Is there a better way to handle the alignment or the projection of these inclined axes?"
