HJTrost

I made a fresh installation of Power PMAC IDE 4.6.0.14 on a new Windows 10 computer. Everything works apparently fine including my programs for/on a CK3C AX1100. The only problem is that the Tune tool does not come up but show an error message Exception thrown by target of an invocation I have tried reinstalling a few times, but the message did not budge. There are two older programs on the system (which I control) that bring in Microsoft Visual C++ Distributables. Are there any scenarios known in which this message would pop up in this way? Cheers, Jochen

Quick addendum: The error message is issued by Intellisense, not Build.

I failed yet again. I have from my homing procedure (drive into the hard end, turn around, look for index): Gate3[0].Chan[0].CaptFlagSel=0 Gate3[0].Chan[0].CaptFlagChan=0 Gate3[0].Chan[0].CaptCtrl=1 I move the setting of UserAlgo.CaptCompIntr=1 from my InitPlc to right before the test move in my script program: cmd"UserAlgo.CaptCompIntr=1"; X(MovEndX) Y(MovEndY) F(FeedRate/1000); While (InPosX==False || InPosY==False) {} The move nominally covers 20 mm and takes some 4 seconds. The encoder is a rotary one on the back of a stepper motor, which produces a motion of 6 mm per revolution, so I should see 3 or 4 calls. I see CaptCompIntr switch from 0 to 1 at the start position of my move but still/again no sign of activity in CaptCompISR - Sys.Idata[65524] remains at 0. Things get messier, actually. My X/Y/F move is not executed properly if I try to get CaptCompISR involved. In the present test with the capture, this means that instead of moving in x from 133333 counts to 159900 counts (1333 counts/mm), the stage takes a detour: 133333 -> 0 -> 159900. In the position compare test, the detour is 133333 -> 200000 -> 159900. I have no idea where that intermediate position comes from. If I keep the position compare a pure script affair, the moves are flawless. Is it time to move this to ODT-Support?

I am pulling this out of my thread "Using CaptCompISR" (https://forums.automation.omron.com/topic/10121-using-captcompisr/) A minimal test version of that function is this: #include "usrcode.h" #define _PPScriptMode_ #include "../Include/pp_proj.h" void CaptCompISR(void) { volatile GateArray3 *MyGate3; int *CompDebug; MyGate3 = GetGate3MemPtr(0); MyGate3->IntCtrl = 0x20; CompDebug = (int *)pushm + 65524; (*CompDebug)++; } It should increase the counter Sys.Idata[65524] by 1 when called and thus prove that it has been called. It does not do this. I do provide a legitimate trigger with script code, which is made visible by a LED. However, the question here is why the Power PMAC IDE flags the declaration of *MyGate3 with a twiddle line under the asterisk and issues the message " syntax error, unexpected '*' ". I have two look-alike motion systems (same hardware, one 15 years old, the other brand new), with the same CK3C controller on each (both brand new out of a delivery of 5 units), with an older Windows 10 laptop assigned to the old system and a new Windows 10 industrial panel PC to the new one. On both, the same version 4.6.0.14 of the IDE is installed, and the firmware reported for the CK3Cs is 2.7.1.0, the cpu is [arm,LS1021A]. Both systems suffer from the same disease. I have found one previous post asking the same question, with no solution reported in the forum. Does anybody have an answer? Jochen

I tried this, and I still don't see any call to CaptCompISR. I edited the function, issued a $$$***, did a Clean in Solution Explorer before Build and Download, issued a "save" after download (because my motion program issues a $$$ at the beginning) and ran my program. The watch window of the IDE says UserAlgo.CaptCompIntr=1 all along and the call counter Sys.Idata[65524] remains at 0. The attached text file shows my usrcode.h, usrcode.c and the relevant script snippet. CaptCompIntr is set much earlier than the occurrence of the move shown in the snippet. The move lasts 4 seconds. usrcode.txt

Yes, I am following pages 792ff. I have put my code for the CaptCompISR function into usrcode.c in the directory "C Language/Realtime Routines". The code follows the Compare Interrupt Routine Example on page 800, with these differences: - I use Chan[1] rather than Chan[0], which allows me to easily switch between triggering off of the positions of my x and y axes. Accordingly, I manipulate the channel-1 bits in Gate3[0].IntCtrl, not the channel-0 bits. - I pick up, from shared memory, the home offset and a direction parameter (+/-1) for setting the proper trigger positions. - I count calls to the interrupt routine with a counter in shared memory. I show this in the watch window, and it never counts a call. - I have removed additional code that I have listed in my original post. In my script programming, - I am setting UserAlgo.CaptCompIntr=1 and can see this in the watch window of the IDE while my program is running; - I am preloading the first trigger position, and this one trigger does fire but is not followed by a call to CaptCompISR. Things that are not addressed in pages 792ff: - In Solution Explorer, the Advanced property "Build Action" of usrcode.c is set to "Compile". I have turned the downloading of the C sources on. On the PMAC, I do find these as well as usralgo.so and usralgo.ko under /var/ftp/usrflash/Project here: Bin/Debug/usralgo.ko Bin/Debug/usralgo.so C Language/Realtime Routines/usralgo.so C Language/Realtime Routines/usrcode.c C Language/Realtime Routines/usrcode.h

More observations: UserAlgo.CaptCompIntr=1 is actually happening. usralgo.so appears in the same directory as usrcode.c and usrcode.h on the PMAC (a CK3C, by the way). I suspect that there are more trivial or stupid omissions in the IDE or project setups to be fixed rather than, or on top of, actual programming issues. I just can't find them ...

I found one omission: In the Solution Explorer, in the Properties of the file usrcode.c, the "Build Action" was still set to "Content". I changed this to "Compile", and now the build-and-download procedure actually compiles my C code. However, when I run my motion system, nothing has changed - "User written 'C' Real Time Interrupt Task is NOT active". And my counter at Sys.Idata[65524] remains at 0, so my CaptCompISR function still does not receive any position-compare trigger.

I am trying to use the C routine CaptCompISR to process position-compare triggers but the C code refuses to run. My general program structure works as follows: Run a oneshot script PLC InitPLC, including an instruction cmd"UserAlgo.CaptCompISR=1"; Start script PLCs for reporting current values (position, velocity, ...) to the host program watch for emergency stop situations handle action requests from the host program I prepare the trigger points for the position compare in Sys.Idata starting at 65536, with the factor 4096 multiplied in but no home offset applied. One action request is handled in a motion script program including the following instructions: Gate3[0].IntCtrl = 0x200000 ; PReadPtr=PVarOffset+TrigPtr ; L1 = PReadPtr ; TrigEnaY = $1 ; // Set EquWrite = $1. TrigAY=(Sys.Idata[L1]/4096-TrigDir*TrigPhs+HmOffset)*4096 ; // This is Gate3[0].Chan[1].CompA TrigBY=TrigAY+TrigDir*PStepAB*ScaleFct*4096; // This is Gate3[0].Chan[1].CompB TriggerPlcR=True ; // Enable plc TriggerPlc ; X(MovEndX) Y(MovEndY) F(CmdFeedRt/1000) ; //Index Through Print. While (InPosX == False || InPosY == False) {} TriggerPlcR=False ; // Disable plc TriggerPlc ; The C code looks as follows: #include "usrcode.h" #define _PPScriptMode_ #include "../Include/pp_proj.h" void CaptCompISR(void) { volatile GateArray3 *MyGate3; int *CompDebug; int *Comp8Million; int *CompType; int *CompCounter; int *CompPosStore; int *CompHmOffset, *CompHmOffsetX, *CompHmOffsetY; int *CompStepAB; int *CompTrigDir; int *CompDataLap; int *CompPVarSize; int Temp, TempPosStore, TempPosTest, Temp8Million, TempM8M, CStepAB, CTrigDir, CpVarSize, CTrigSel; MyGate3 = GetGate3MemPtr(0); MyGate3->WpKey = 0xAAAAAAAA; // Make IntCtrl writeable. MyGate3->IntCtrl = 0x20; // Clear interrupt. CompDebug = (int *)pushm + 65524; // Debug counter, serves to prove that this code is executed. CompPVarSize = (int *)pushm + 65525; CompTrigDir = (int *)pushm + 65526; CompStepAB = (int *)pushm + 65528; CompHmOffset = (int *)pushm + 65531; CpVarSize = *CompPVarSize; CTrigDir = *CompTrigDir; // Direction of motion - +1 or -1 CStepAB = *CompStepAB; CompDataLap = (int *)pushm + 65532; // Wrap-around flag, 0 or 1. Comp8Million = (int *)pushm + 65533; // end of run flag value. Temp8Million = *Comp8Million; TempM8M = - Temp8Million; CompType = (int *)pushm + 65534; // 0 for rectangular flying, 1 for curved flying. CompCounter = (int *)pushm + 65535; // The value for this index was preloaded, (*CompCounter)++; // so we point to the second value first time we get here. if (*CompCounter >= CpVarSize) { *CompCounter = 0; *CompDataLap = 0; } CompPosStore = (int *)pushm + *CompCounter + 65536; TempPosStore = *CompPosStore; TempPosTest = TempPosStore / 4096 ; (*CompDebug)++; // Counts calls here. if ((*CompType) == 0) { if ((TempPosTest < Temp8Million) && (TempPosTest > TempM8M)) { // Set new trigger point. MyGate3->Chan[1].CompA = TempPosStore + *CompHmOffset ; MyGate3->Chan[1].CompB = TempPosStore + *CompHmOffset + CStepAB * CTrigDir; // Set EquWrite = 1. Temp = MyGate3->Chan[1].OutCtrl; Temp &= 0xFFFFFF7F; // Clear bit 7 (0x80). MyGate3->WpKey=0xAAAAAAAA; // Make OutCtrl writeable. MyGate3->Chan[1].OutCtrl = Temp | 0x40; // Set bit 6. } } else if ((*CompType) == 1) { // ... case not used yet ... } } My usrcode.c file does also contain the dummies for other functions like GetLocal and CFromScript. The source gets actually downloaded, I have found it with Putty on the PMAC. If I disable the instruction to set CaptCompISR=1 in InitPlc and activate my script PLC "TriggerPlc" in the motion program, I get to see all expected triggers. Here is how TriggerPlc works: Open plc TriggerPlc //Trigger Target Generator. If (TrigStateY == True) // Test Gate3[0].Chan[1].Equ { p793=p793+1; // Debug counter TrigPtr=TrigPtr+1 ; If (TrigPtr == pVarSize) { TrigPtr=0 ; DataLap=False ; } PReadPtr=(PVarOffset+TrigPtr) ; L1 = PReadPtr ; TrigEnaY = $1 ; // Set EquWrite = $1. TrigAY=(Sys.Idata[L1]/4096-TrigDir*TrigPhs+HmOffset)*4096 ; // This is Gate3[0].Chan[1].CompA TrigBY=TrigAY+TrigDir*PStepAB*4096; // This is Gate3[0].Chan[1].CompB } Close The IDE does not like the statement volatile GateArray3 *MyGate3; It puts a red twiggle under the "*" of *MyGate3 and reports "syntax error, unexpected '*'". Of my script PLCs, only TriggerPlc is a RTIPLC. Sys.WpKey is globally set to $AAAAAAAA. I have set the build and download to include the C source code. The build and download does not report any error. When trying to run this code, the task list reports under "Real time interrupt" "User written 'C' Real Time Interrupt task not active". What am I missing? Cheers, Jochen

In position-compare triggering, I need to handle a range of 300 mm worth of quadrature encoder counts of 0.1 micron, i.e., 3 million. The trigger positions need to be stuffed into Gate3[0].Chan[1].CompA and .CompB for the leading and trailing edges of the TTL pulses. The units of CompA and CompB are 1/4096th of an encoder count, leaving a range of 20 bits for the full encoder counts, or about 1 million. With the Turbo PMAC family, I had 24 bits for a full range of 16 million plus. My encoder settings are Gate3[0].Chan[j].EncCtrl=3 or 7 (j=0, 1). Now the Power PMAC Software Reference Manual says this, under Gate3[i].Chan[j].CompA (last paragraph): In the Script environment, it is possible to write values from -2^31 to +2^31-1 to this element. (An attempt to write a value outside this range will cause the element value to saturate at the end of this legal range.) That is, for writing purposes, it can be treated as either a signed 32-bit value with a range of -2^31 to 2^31-1 or an unsigned 32-bit value with a range of 0 to 2^32-1. However, for reading purposes, it is always reported as an unsigned value, so if it is set to a negative value, the value reported will be 2^32 greater than that value. Note the second sentence, in parentheses: "An attempt to write a value outside this range will cause the element value to saturate at the end of this legal range." I understand this to mean that there is no rollover mechanism but rather a Procrustean bed, i.e., excess values are truncated down to the limit value. What are my options? Can CompA and CompB be made to operate on different units, e.g., with one unit in CompA and CompB being worth 1000 of my encoder counts? My trigger position set points need to be accurate to the 1 micron level, not 1/4000th of 0.1 micron.

Progress! Reordering the code by writing to EquWrite first and CompA and CompB thereafter makes the electric trigger pulses appear. Gate3[0].Chan[1].EquWrite=$1; // clear output signal Gate3[0].Chan[1].CompA=(P(P606)+Motor[1].HomePos)*P2999; Gate3[0].Chan[1].CompB=(P(P606)+P611+Motor[1].HomePos)*P2999; So the enabling of the autoincrement operation does actually more than that as my CompAdd is at default, i.e., 0. That leaves the 300 mm in 0.1 micro steps encoder issue. I'll open a new thread for that one.

Yes, that is intentional. By flipping Equ1Ena, using Chan[1] allows me to change the axis selection for the triggering on the fly. A working pair of programs is attached, updated slightly from my previous inline quotes. Setting Gate3[0].Chan[1].Equ1Ana=0 and using Motor[2] instead of Motor[1] converts this from the x axis to the y axis. This is what we did with the Turbos. "Working program" means I get the state changes of Equ and EquOut in software and count the correct number of trigger pulses (counter p793). The CK3C still does not give me the TTL pulses. TestTrig.pmc TriggerTestPlc.plc

It took me a while but I think I am finally getting a grip on this. The cutting off of the trigger in software that I am used to from the Turbo PMAC does not work here, and I need CompA and CompB to define the pulse length. The scaling with 4096 is correct. My motor units are quadrature encoder counts. So my trigger update looks like this: Gate3[0].Chan[1].CompA=(P(PReadPtr)+Motor[1].HomePos)*4096 ; Gate3[0].Chan[1].CompB=(P(PReadPtr)+50+Motor[1].HomePos)*4096 ; Gate3[0].Chan[1].EquWrite=$1 ; //Clear old Trigger. Here I have previously set Gate3[0].Chan[1].Equ1Ena=1 to get the x axis triggers on the EQU2 output line. I can flip Equ1Ena on the fly and thereby accommodate curved motions, in which triggering in the x-y plane uses the larger of the x and y projections. My problem now is that the hardware pulses do not show up on the EQU2 line, pin 18 of the JMACH2 port of the CK3C. I have yet to take an oscilloscope to it for a close look. But as there is no user manual for the CK3C yet, I'd like to know if that output pulse still is supposed to be a TTL pulse of 5 V amplitude. I also need to know what happens when the motor counts in .CompA and .CompB roll over as they will on my 300 mm long motion stages with 0.1 micron quadrature counts.

I have looked through those passages before, and I've looked again. I just don't recognize the answer there. My trigger strategy goes like this: Load first trigger point into CompA. Start the move of the stage. When Equ has turned on, load the next trigger point into CompA. Clear the old trigger by writing to EquWrite. When Equ has turned on, load the next trigger point into CompA. Clear the old trigger by writing to EquWrite. Here is the core of my program code: Open plc TriggerPlc If (Gate3[0].Chan[1].Equ == 1) { TrigPtr=TrigPtr+1 ; //Increment Pointer. If (TrigPtr == 60000) { TrigPtr=0 ; DataLap=False ; } PReadPtr=(3000+TrigPtr) ; Gate3[0].Chan[1].CompA=(P(PReadPtr)+Motor2.HomePos)*4096 ; Gate3[0].Chan[1].EquWrite=$1 ; //Clear old Trigger. } Close I have no use for the increment, it is left at its default, which should be zero. I have no use for CompB either, which I set to an out-of-range-of-interest position (8,000,000 for the Turbo PMAC, currently 80,000,000 for the CK3C). I don't see what keeps me from getting trigger output signals.

I am trying to get triggering on hardware position converted from Turbo PMAC to Power PMAC. On Turbo PMAC I use the 24-bit full encoder counts registers M108 or M208. This gives me a range of 16,000,000+ encoder counts, sufficient for 300 mm of counts at 0.1 micron/count. I do not bother with the fractional counts in M188 and M288. Now, if I understand the Power PMAC User Manual correctly, I have to put my trigger position into Gate3[0].Chan[j].CompA in units of 1/4096 encoder counts and am thus limited to just over 1,000,000 full encoder counts range (20 bits rather than Turbo's 24). So I essentially write CompA = (myTrigPosition + HomeOffset) * 4096 ; and take a run of the respective motion stage to see the trigger light up. On the Turbo PMAC the equivalent (no 4096, of course) works. On the Power PMAC, I do not see any triggers - I have put CompA into my watch window in Power PMAC IDE, and I know that the value of myTrigPosition is valid and within my motion range for the trigger run. HomeOffset stands for M173 or M273 on Turbo PMAC and Motor[x].HomePos on Power PMAC. There is one oddity in my programs: When I am moving about without triggering, CompA and CompB are set to 8,000,000 on the Turbo PMAC and (because I thought initially that the Power PMAC gives me *more* range) 80,000,000 on the Power PMAC; the autoincrement is always 0. I don't touch CompB any further. When triggering, I preload the first sensible value into CompA and then start the move. Once a trigger shows up in Gate3[0].Chan[j].Equ, I clear the trigger in software with EquWrite = $1 and set the next value in CompA. Where am I losing it on the Power PMAC? How do I accommodate my 3,000,000 encoder counts on the Power PMAC? I'd absolutely hate to have to throw virtual motors in there with scaled virtual encoders (e.g., virtual = real / 4096, which would give me 32 bits of full encoder counts). Hans-Jochen Trost

As I am now working with a CK3C AX1100 and PMAC IDE 4.6.0.14 and still observe the same problem, I revisited the topic (SSH Timeout) that Leandro pointed to in one of his answers. It does indeed solve my problem. I set ClientAliveInterval=0 through the IDE as shown there, and it even takes care of making it permanent. The earlier version of the PMAC IDE that I was using (4.4.0.99) does not offer this access to the Client-Alive parameters.

Steve, thanks for the detailed instructions. Jochen

I am back at setting up motors in the Power PMAC IDE. Rather than IDE 4.4.0.99 and a PowerPMAC 465 Clipper with a PowerPC,APM86xxx CPU and firmware 2.5.2.0, I am now using 4.6.0.14 and a CK3C AX1100 with an arm.LS1021A CPU and firmware version 2.7.1,0. My system uses IM483H-Plus amplifiers operating in torque mode and issuing step & direction control signals, Schneider M-2218-3.0 and M-2231-3.0 stepper motors with 200 full steps per rev, and US Digital E6 rotary encoders with 2000 lines/rev and quadrature. I use a single feedback type setup. The amplifier goes in fine. The motor shows a yellow triangle with an exclamation mark for an error message saying: "Your changes cannot be saved as there are validation errors. Please review the entered information." Yet when I open the motor definition, it has all the information required and there is no complaint shown. If I rudely redeclare the motor to be a brush motor rather than stepper, the IDE will take it at the expense of a yellow triangle for the encoder (same error message as above) and an additional note in the encoder box saying "No supported encoder definitions have been created for this motor. To create an encoder click here." Yet there is already the US Digital E6 decoder defined with the corresponding parts manager. An attempt to select it as the primary encoder creates a pop-up error message "The encoder on this Motor Configuration could not be selected because it is not supported by the connected device." An additional question is what do I do to my script language code: Do I have to replace all references to Clipper[x] with CK3C[x] ? (This becomes an issue once I got the motor definition matter resolved.) What am I missing, or what have I lost now? Jochen

I solved the Code 58 issue. I had messed up the driver installation, putting incompatible component versions together. Device Manager still reports a UMAC but the setup now works as it should. That leaves my primary question here open: Which E-jumpers do I absolutely have to install?

Additional information: I added jumpers on E11 and E12, theD3 LED is still red. Windows reports the Clipper as a "Delta Tau UMAC USB 2.0 Device". That was previously for the Turbo Clippers we used "Delta Tau PMAC USB 2.0 Device". There is a yellow warning triangle at the Clipper entry in Device Manager. The Properties window for this device reports: "The software for this device has been blocked from starting because it is known to have problems with Windows. Contact the hardware vendor for a new driver. (Code 48)" I am using a laptop with Windows 7 64-bit right now and have PEWinPro and PEWInPeo2 both on it. Neither is willing to find the device.

We bought a Turbo Clipper model 4-3871C3-2005-300000 in the secondary market. It came with just one jumper installed, on header JP1. When we powered the board up, the watchdog LED D3 came up red immediately. We had a miscue by putting the 50-wire ribbon cable on in reverse, which in effect connected +5 V on our side at pin 47 to pin 4 (GND) on the Clipper, and which we fixed after a few minutes. Pins 1-4 and 48-50 are not connected to anything on our side, so I hope that we may have a chance for not having burned up any component. I need to know if missing all E jumpers would lead to the D3 LED lighting up red, and I need to know which jumpers need to be present at a minimum to make the board work. We have connections for the power supply TB1, JMACH1 (50 pin), JMACH2 (37 pin) and USB communication. From the hardware reference manual I gathered that jumper E7 ("related to USB/Ethernet reset") would be absolutely necessary to have in place, so I put a jumper on it. My next candidates would be E11 and E12 related to reset at power-up. I appreciate any suggestions.

More trials. ClientAliveCountMax=3 and ClientAliveInterval=15 are in /etc/ssh/sshd_config. Setting ClientAliveInterval=150, uploading it with my WinSCP FTP client and the running my application does not change my results, i.e., after a wait time of 60 seconds I do not get a response anymore. I tried successively 15, 20, 25, ... , 65 seconds, and at 65 seconds the accident happened. If I power-cycle the PMAC, the uploaded version of sshd_config has reverted to the old original (imported from /.readonly/etc/ssh/sshd_config ?). As my application logs in separately from the FTP client (and Putty which I have open for looking), where does it get its settings? Cheers, Jochen

Leandro, it sure looks like it. However: I do not have the selection "Tools -> Options -> Power PMAC -> Communication Settings available. There are no entries ClientAliveCountMax or ClientAliveInterval in /etc/ssh/ssh_config. There is an entry "ConnectTimeout 0" in /etc/ssh/ssh_config. I am working with Power PMAC IDE 4.4.0.99 with firmware 2.5.2.0. I have a newer version of the IDE at hand but not a 2.6.x version of the firmware, and the newer IDE does not like the 2.5.x firmware. My host system is Windows 10 but my application program is 32-bit, having a 25+ year history of development in it. So what are my options now?

I am working on converting my Turbo PMAC software to Power PMAC and have made some good progress. My application program starts, initialized the 3-stage system (Cartesian x, y z) and makes abs-linear moves, abs-rapid moves and velocity jog oves just fine. Homing is also under control. My problem is that as soon as I take a 1 minute break before asking for the next move, the controller does not respond any longer - actually, no command goes through to the controller. I have a Power PMAC Clipper 465. My control program sits on a Windows 10 laptop. I use the libssh2 implementation from Observatory Sciences to let my control program talk to the PMAC. OF the many "system" calls in the Observatory Sciences package, I use just 3: _connect(192.168.0.200, root, password, 22, use-minus-2) _sendCommand(command,reply) _disconnect() When the accident happens, _sendCommand reports no bytes written. One level down in the package, this function attempts writing by a call to _write(buffer, buffersize, byteswritten, timeout) which issues the report that _sendCommand offers. The calling continues into SSHDriver::write(buffer, buffersize, byteswritten, timeout) and that finally calls libssh2_channel_write(channel, buffer, buffersize) This function is part of the libssh2 library, specifically version 1.4.3, of which Observatory Sciences included the finished DLL but no source. It reports an error -43, which I found in another source (for libssh2 1.10.0) to be named LIBSSH2_ERROR_SOCKET_RECV. At this point I have to close my program - the _disconnect() call apparently succeeds. Starting my application right away does also work, same whole story, so disconnect/connect clears the problem. That is of course not anacceptable behavior. If I keep a terminal window open on my laptop, I can ping the controller just fine after the accident has happened. If I start the Power PMAC IDE before my application program and just let it sit (connected to the PMAC), it will take and execute a simple jog command like #1j:50000 (about 37 mm distance) after the accident has happened. The Power PMAC IDE does not show any such behavior, it survices tea time just fine. Question: Has anybody seen this or similar behavior before, and if so, what was the solution? Cheers, Jochen

That did it. ServoCapt.a and ScaleFactor=1/256 are what I need. Now the motors behave quite like I am used to seeing.