Connecting with Weco E12

[Ryan]

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.

[Yaron [LaserOp]]

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

[Ryan]

I have attached the information we send to the WECO E12 including the trace.

I appreciate you assistance.

WECO E12 English Log.txt

[Yaron [LaserOp]]

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